# ticket

tkt_uuid: 749016ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Duplicate
title: spinbox.test fails
comment:
  This test fails on Tru64Unix 5.1A with tcl8.4.3/tk8.4.3
  and tcl8.4.3/tk-cvs:


  ==== spinbox-5.7 ConfigureSpinbox procedure FAILED
  ==== Contents of test case:

      catch {destroy .e}
      spinbox .e -font $fixed -width 4 -xscrollcommand scroll
      pack .e
      .e insert end "01234567890"
      update
      .e configure -width 5
      set scrollInfo

  ---- Result was:
  0.315789 0.842105
  ---- Result should have been (exact matching):
  0 0.363636
  ==== spinbox-5.7 FAILED


  ==== spinbox-7.1 InsertChars procedure FAILED
  ==== Contents of test case:

      .e delete 0 end
      .e insert 0 abcde
      .e insert 2 XXX
      update
      list [.e get] $contents $scrollInfo

  ---- Result was:
  abXXXcde abXXXcde {0.315789 0.842105}
  ---- Result should have been (exact matching):
  abXXXcde abXXXcde {0 1}
  ==== spinbox-7.1 FAILED


  ==== spinbox-17.4 SpinboxUpdateScrollbar procedure FAILED
  ==== Contents of test case:

      destroy .e
      set x "Background error did not happen"
      proc bgerror msg {
          global x
          set x $msg
      }
      spinbox .e -width 5 -xscrollcommand thisisnotacommand
      pack .e
      update
      rename bgerror {}
      list $x $errorInfo

  ---- Result was:
  {Background error did not happen} {bad spinbox index "1xyz"
      while executing
  ".e index 1xyz"}
  ---- Result should have been (exact matching):
  {invalid command name "thisisnotacommand"} {invalid
  command name "thisisnotacommand"
      while executing
  "thisisnotacommand 0 1"
      (horizontal scrolling command executed by .e)}
  ==== spinbox-17.4 FAILED


  ==== 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:

  ---- Result should have been (exact matching):
  .e -1 -1 abcd abcd {} focus focusin
  ==== spinbox-19.8 FAILED


  ==== spinbox-19.9 spinbox widget validation FAILED
  ==== Contents of test case:

      focus -force .
      # update necessary to process FocusOut event
      update
      set ::vVals

  ---- Result was:

  ---- Result should have been (exact matching):
  .e -1 -1 abcd abcd {} focus focusout
  ==== spinbox-19.9 FAILED


tkt_uuid: 749018ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Invalid
title: text.test fails
comment:
   This test fails on Tru64Unix 5.1A with tcl8.4.3/tk-cvs
   but NOT tcl8.4.3/tk8.4.3(maybe it's expected when
   messing up versions). But in case of tcl8.4.3/tk8.4.3
  text-15.2 was failing(so that is fixed in cvs).



  ==== text-6.14 TextWidgetCmd procedure, "compare"
  option FAILED
  ==== Contents of test case:

      list [catch {.t co 1.0 z 1.2} msg] $msg

  ---- Result was:
  1 {bad option "co": must be bbox, cget, compare,
  configure, debug, delete, dlineinfo, dump, edit, get,
  image, index, insert, mark, scan, search, see, tag,
  window, xview, or yview}
  ---- Result should have been (exact matching):
  1 {ambiguous option "co": must be bbox, cget, compare,
  configure, debug, delete, dlineinfo, dump, edit, get,
  image, index, insert, mark, scan, search, see, tag,
  window, xview, or yview}
  ==== text-6.14 FAILED


tkt_uuid: 749088ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 8
foundin: obsolete: 8.5a0
resolution: Fixed
title: configure should check version of tcl
comment:
  Please read
  https://sourceforge.net/tracker/?func=detail&atid=112997&aid=748977&group_id=12997

  Based on that, please make sure configure exits
  properly when user does not have installed required
  version of tcl. For example, I find legitimate using
  latest tk from cvs and latest release of tcl. But, that
  seems not at least in case of tktest dumping core.


tkt_uuid: 749353ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 8
foundin: obsolete: 8.4.3
resolution: Fixed
title: Tk crash on exit in tkImage.c
comment:
  Please use the following steps to reproduce the problem:

  #1. Run the attached game script on a Windows 
  machine (not sure if the bug manifests itself on Unix).
  #2. The game has been modified so that it will 
  continuously cascade. Simply swap two of the pieces 
  and watch the action fly for a while.
  #3. Attempt to exit the game by closing the window.

  This bug works equally well with 8.4.x and the current 
  CVS HEAD.

  Tk will crash upon calling Tcl_DeleteHashEntry in 
  tkImage.c near line #680:

      if ((masterPtr->typePtr == NULL) && (masterPtr-
  >instancePtr == NULL)) {
          Tcl_DeleteHashEntry(masterPtr->hPtr);
  ckfree((char *) masterPtr);
      }

  Based on my research, it appears that Tk is attempting 
  to delete an already deleted hash entry.

  If you change the code to the following, the crash is not 
  seen:

      if ((masterPtr->typePtr == NULL) && (masterPtr-
  >instancePtr == NULL)) {
          if (!masterPtr->deleted) {
             Tcl_DeleteHashEntry(masterPtr->hPtr);
          }
  ckfree((char *) masterPtr);
      }

  Since I am not an expert in Tk, I am not sure if this 
  slight modification gets to the "heart" of the actual 
  problem.  For example, why would Tk attempt to delete 
  the same hash entry twice?

  Here is the stack trace:

  Tcl_DeleteHashEntry(Tcl_HashEntry * 0x00dc8f28) line 
  518 + 3 bytes
  Tk_FreeImage(Tk_Image__ * 0x00db0680) line 680 + 19 
  bytes
  DeleteImage(Tk_Canvas_ * 0x00dd04b8, Tk_Item * 
  0x00e2c9b0, _XDisplay * 0x009c32c0) line 412 + 12 
  bytes
  DestroyCanvas(char * 0x00dd04b8) line 1951 + 24 bytes
  Tcl_Release(void * 0x00dd04b8) line 241 + 7 bytes
  CanvasBindProc(void * 0x00dd04b8, _XEvent * 
  0x00e2ccb8) line 4537 + 16 bytes
  Tk_HandleEvent(_XEvent * 0x00e2ccb8) line 1010 + 17 
  bytes
  WindowEventProc(Tcl_Event * 0x00e2ccb0, int -3) line 
  1414 + 12 bytes
  Tcl_ServiceEvent(int -3) line 625 + 11 bytes
  Tcl_DoOneEvent(int -3) line 930 + 9 bytes
  Tk_MainLoop() line 1472 + 13 bytes
  Tk_MainEx(int 1, char * * 0x00866e20, int (Tcl_Interp *)
  * 0x004010b9 Tcl_AppInit(Tcl_Interp *), Tcl_Interp * 
  0x0086ade8) line 284
  WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 
  0x00000000, char * 0x001335d5, int 1) line 130 + 26 
  bytes
  WinMainCRTStartup() line 330 + 54 bytes


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: 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: 749908ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 74. Application Embedding
priority: 7 High
foundin: obsolete: 8.4.11
resolution: Accepted
title: problems with threaded Tk and multiple interps
comment:
  The platform in question is Windows NT/2000.

  If I start up tetris.tcl, then close it, then try to run it 
  again in the same interp, 
  I get the usual (expected) error message "can't invoke 
  wm command, app has been 
  destroyed". However, if I then delete the interpreter, 
  create a new one, and attempt 
  to run tetris.tcl, I get:

  bad screen 
  distance "aaaaaaaaaaaaaaaaaaaaïÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
  ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍï0ïD"
      (default value for "HOME" in 
  widget ".r.board")
      invoked from within
  "canvas $widget(board) -width $tetris(width) -
  height $tetris(height)  -bg gray"
      (procedure "Init" line 85)
      invoked from within
  "Init"
      (in namespace eval "::Tetris" script line 
  1319)
      invoked from within
  "namespace eval Tetris {;
  variable tetris
  variable block
  variable players
  variable stats
  variable pmap
  variable piece
  variable widget
  ## VERSION:
  set..."
      (file "tetris.tcl" line 25)
      invoked from within
  "source "tetris.tcl""

  Some digging reveals the offending code may be in 
  tkOldConfig.c.
  Similar garbage is displayed if you try to re-run the Gem 
  Game.
  In addition, a panic caused by TlsFree failing results if 
  you attempt 
  to exit the process after creating an interpreter with Tk, 
  delete it, 
  and create another one.

  This is definately a recent issue as I know I've done this 
  sort of thing 
  with 8.3.x and [i believe] 8.4.x.  

  I cannot imagine how this behavior could be by design.


tkt_uuid: 751553ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: Xft: [font configure] does not update in-use fonts
comment:
  With --enable-xft:

  % font create f -family Times
  % font actual f
  -family Times -size 12 -weight normal -slant roman
  -underline 0 -overstrike 0
  % font configure f -family Helvetica 
  % font actual f ;# works as expected:
  -family Helvetica -size 12 -weight normal -slant roman
  -underline 0 -overstrike 0

  % pack [text .t -font f]
  % font configure f -family Times
  % # Text widget .t  is not updated; [font actual] shows
  no change
  % font actual f
  -family Helvetica -size 12 -weight normal -slant roman
  -underline 0 -overstrike 0


tkt_uuid: 752547ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 07. [entry]
priority: 5 Medium
foundin: None
resolution: Invalid
title: need allow users input entry fields in non-utf encodings
comment:
  Hi,
   I have  been developing a software using Tcl/Tk 8.4.3,
  and had problems with calling to Tk library from inside 
  a C application via Tcl_Eval, when the string to type
  into entry
  field was in non-utf8 encoding, it had to be first
  transported there
  with appropriate 'Tcl_ExternalToUtfDString' call.
   
  The following patch has to be done to tkEntry.c

  --Alex

  diff -ruN tk8.4.3/generic/tkEntry.c
  tk8.4.3c/generic/tkEntry.c
  --- tk8.4.3/generic/tkEntry.cTue Feb 25 03:46:41 2003
  +++ tk8.4.3c/generic/tkEntry.cSat Jun  7 13:01:28 2003
  @@ -19,6 +19,7 @@
   
   #include "tkInt.h"
   #include "default.h"
  +#include <tcl.h>
   
   enum EntryType {
       TK_ENTRY, TK_SPINBOX
  @@ -1035,7 +1036,28 @@
           goto error;
       }
       if (entryPtr->state == STATE_NORMAL) {
  -
          InsertChars(entryPtr, index,
  Tcl_GetString(objv[3]));
  +
  +
  +/*         InsertChars(entryPtr, index,
  Tcl_GetString(objv[3]));
  + */
  +
  /*alexalex*/
  +

  +
  char * val;
  +
  Tcl_DString * dstPtr;
  +

  +
  dstPtr =  (Tcl_DString *) ckalloc(sizeof(Tcl_DString));
  +

  +
  val = Tcl_GetString(objv[3]);
  +
  if ((entryPtr->numChars != 1) && strlen(val) == 1) {
  +

  +  InsertChars(entryPtr, index, 
  +
  Tcl_ExternalToUtfDString(Tcl_GetEncoding(NULL,
  Tcl_GetEncodingName(NULL)),val, 1, dstPtr));
  +
  }
  +
  else {
  +
  InsertChars(entryPtr, index, val);
  +
  }
  +
  +
  /*alexalex*/


tkt_uuid: 755530ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 8
foundin: None
resolution: Fixed
title: XIMPeek wrong for newer XFree86, panics
comment:
  As reported by dliigent Debian user Geoffrey Lee at
  <http://bugs.debian.org/170504>, the XIMPeek structure
  added to unix/tkUnixEvent.c in 8.4.1 does not
  correspond to the X internal (hidden) _XIM structure,
  at least not with the latest versions of XFree86.  The
  XFree86 _XIM structure has one additional member before
  the input context pointer.  The result is spurious
  panics with the message "input contexts not freed
  before XCloseIM".

  The code in question can be seen with "cvs diff
  -rcore-8-4-0 -rcore-8-4-1 tkUnixEvent.c".  This is the
  only change made to tkUnixEvent.c between 8.4.0 and 8.4.1.

  The comments in the patch suggest that this was added
  as a workaround to certain buggy implementations of
  X11.  (Solaris 2.3  1/6/95 is mentioned.)  Presumably,
  it was made into a default on the theory that struct
  _XIM would be the same across platforms and the test
  would therefore be harmless.  Either this theory has
  been proven incorrect, or the patch is just broken, and
  needs one extra "junk" member in the XIMPeek structure.
   If the former, then perhaps the patch should be made
  conditional for just those platforms that are known to
  need it; if the latter, perhaps the new junk member
  should just be added.

  I don't have a Solaris 2.3 system to check, so I'm not
  sure what the proper approach would be.


tkt_uuid: 755906ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 61. Safe Tk
priority: 9 Immediate
foundin: None
resolution: Fixed
title: free of uninitialized DString in tkWindow.c
comment:
  in generic/tkWindow.c, near line 2938, there is the 
  following code:

    if (Tcl_IsSafe(interp)) {
  <snip>
  Tcl_DString ds;
  <snip>
  while (1) {
      master = Tcl_GetMaster(master);
      if (master == NULL) {
  Tcl_DStringFree(&ds);

  I believe the call to Tcl_DStringFree is an error. The 
  variable "ds" does not actually get initialized until later, 
  near line 2978. Attempting to free this invalid DString 
  causes a crash in the debug build of the HEAD. This 
  same bug also exists in the core-8-4-branch.


tkt_uuid: 756840ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 9 Immediate
foundin: obsolete: 8.5a2
resolution: Fixed
title: thread finalize crash with console
comment:
  When Tcl_FinalizeThread is called for a thread that has a 
  console, it eventually calls TclFinalizeIOSubsystem, 
  which calls Tcl_Close for the console channel(s).  At 
  some point TkConsolePrint is called by the Tcl IO 
  subsystem.  In the included stack trace, TkConsolePrint 
  is trying to do various things with the interpreter, which 
  seems to have been already deleted.

  Tcl_GetCurrentNamespace(Tcl_Interp * 0x027b0b10) line 
  207 + 6 bytes
  Tcl_FindCommand(Tcl_Interp * 0x027b0b10, const char 
  * 0x0267d344, Tcl_Namespace * 0x00000000, int 0) line 
  1987 + 9 bytes
  Tcl_GetCommandInfo(Tcl_Interp * 0x027b0b10, const 
  char * 0x0267d344, Tcl_CmdInfo * 0x0306fd78) line 
  2207 + 17 bytes
  TkConsolePrint(Tcl_Interp * 0x027b0b10, int 8, const 
  char * 0x03507b00, long 0) line 798 + 25 bytes
  ConsoleOutput(void * 0x00000008, const char * 
  0x03507b00, int 0, int * 0x0306fde0) line 420 + 23 bytes
  FlushChannel(Tcl_Interp * 0x00000000, Channel * 
  0x027db000, int 0) line 2066 + 38 bytes
  CheckFlush(Channel * 0x027db000, ChannelBuffer * 
  0x03507ae0, int 0) line 3413 + 13 bytes
  WriteChars(Channel * 0x027db000, const char * 
  0x024ad744, int 0) line 3206 + 17 bytes
  Tcl_Close(Tcl_Interp * 0x00000000, Tcl_Channel_ * 
  0x027db000) line 2540 + 16 bytes
  TclFinalizeIOSubsystem() line 243 + 11 bytes
  Tcl_FinalizeThread() line 933


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: 758100ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: None
title: Borland patches for 8.5
comment:
  Hello out there,
  enclosed are the patches necessary to succesfully build
  Tk (8.5) with Borland (well, it requires that Tcl can
  be built with Borland, too, but these patches are at SF
  as well).
  Best regards
  Helmut Giese


tkt_uuid: 758123ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Invalid
title: Xft: wrong fonts selected for display
comment:
  Georgios Petasis reports on comp.lang.tcl that on his
  system (RH9, with MS Unicode fonts installed), buttons
  and other Tk widgets are displayed in a serif font
  instead of a sans-serif one as expected:

  http://groups.google.com/groups?threadm=bbk4hl%24278g%241%40ulysses.noc.ntua.gr


tkt_uuid: 759550ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: None
resolution: Invalid
title: tkFont.Font(name=existing) is an error
comment:
  The following demonstrates the error:

  >>> from Tkinter import *
  >>> root = Tk()
  >>> import tkFont
  >>> f = tkFont.Font()
  >>> str(f)
  'font2881056'
  >>> f2 = tkFont.Font(name=str(f))
  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk/tkFont.py", line 76, in __init__
      root.tk.call("font", "create", name, *font)
  _tkinter.TclError: named font "font2881056" already exists

  What I do is create a few named fonts (tkFont.Font objects) as I start a GUI application and use those to set the option database before creating any widgets. Then the user can modify the tkFont.Font objects to change the fonts used by all the widgets. Everything live-updates. A bit slowly perhaps, but it's very nice. So far so good.

  However, I would like some way to recreate the tkFont.Font object from a widget that uses it, so I don't have to keep the tkFont.Font objects around after I create them.

  Note that: f2 = tkFont.Font(font=wdg["font"]) does not work. f2 is created and has the right settings, but it has the wrong name, so modifying f2 does not modify wdg or any other widgets.

  One thing that does work is:
  f2 = tkFont.Font()
  f2.name = wdg["font"]
  but this creates a new Tk named font which is never used, so I'd be leery of using it.

  -- Russell

  P.S. as an aside, there is a similar issue with Tkinter variables. However, there is a reasonable workaround for variables: getvar and setvar. Unfortunately there are no equivalent functions for tkFont.Font objects.


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: 765642ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 74. Application Embedding
priority: 8
foundin: obsolete: 8.4.3
resolution: None
title: [load] Tk needs Tcl's --prefix
comment:
  During a [load <Tk>], the Tk_Init() routine runs.

  In turn, it tries to eval the [tcl_findLibrary] command
  to find the installed tk.tcl file.

  If Tk was installed with TK_PREFIX the same as
  Tcl's TCL_PREFIX, then this will succeed.

  However, if Tk is installed somewhere else, and
  a Tcl interpreter tries to [load] it, there will be an
  error as Tk is unable to find the tk.tcl file.  This means
  that Tk will not work correctly since it did not get
  initialized.

  There are a number of partial solutions possible.

  Tk's configure/build/install could be constrained
  to force TK_PREFIX to be the same as TCL_PREFIX.
  However, that just means the Tk will be [load]able
  in the Tcl installation it was configured against.
  The bug will remain when trying to [load] the same
  Tk shared library in a different Tcl installation.

  As requested in Tcl Feature Request 695441,
  [tcl_findLibrary] could be extended to also search
  directories on the auto_path.  This would workaround
  this bug in the most common case where the [load]
  is wrapped inside the mechanics of [package require],
  and the search for require-able packages is done
  using [tclPkgUnknown] -- the default [package unknown] 
  handler -- which is influenced by the value of ::auto_path.
  This will not fix the bug for direct [load]s though.

  Ultimately, the problem is that Tk_Init() needs a
  better tool/strategy for finding its script library than
  [tcl_findLibrary] is capable of providing.  Since the
  Tcl world now includes virtual file systems, the
  ultimate solution may require embedding Tk's
  script library into the binary library itself as an
  internal file system so that this problem of finding
  and joining two separately installed pieces of Tk
  just goes away.

  Short of that, a revised installation strategy that
  installs the Tk script library under TK_EXEC_PREFIX
  in the same directory as Tk's pkgIndex.tcl file
  would also be a solution.  There would be no need
  for a [tcl_findLibrary] call.  The pkgIndex.tcl file
  would just arrange for

      source [file join $dir tk.tcl]

  to be part of Tk's package loading script.  The cost
  of that solution is that on multi-architecture
  installations,
  each architecture gets its own copy of the Tk script
  library installed -- costing some disk space and
  costing some maintenance effort for those installations
  that make customizations to the script library.


tkt_uuid: 767009ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: Unused variable warning in tkTextDisp.c
comment:
  gcc reports that there is an unused variable in the 
  function DisplayText in tkTextDisp.c

  ..../generic/tkTextDisp.c: In function `DisplayText':
  ..../generic/tkTextDisp.c:2247: warning: unused variable 
  `flags'

  This sort of thing often indicates some kind of problem, 
  but is sometimes just an indication that there's a 
  variable that is now simply surplus to requirements due 
  to code changes (or even an accidental check-in!)


tkt_uuid: 767176ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 8
foundin: obsolete: 8.4.3
resolution: Fixed
title: Bad winPtr->window pointer causes crash in Tk_GetHWND
comment:
  This is a somewhat obscure and intermitted crash,
  demonstrated by the attached script which requires
  Bryan Oakley's combobox implementation (demonstrated
  with version 2.2.1).  An access violation occurs when
  WmProc() in tkWinWm.c gets called with a WM_ACTIVATEAPP
  event.  This isn't in the switch so it goes on to get
  winPtr:

  winPtr = GetTopLevel(hwnd);

  Unfortunately, the value sometimes comes up bogus
  (filled with bad pointers and such) and when it
  subsequently calls Tk_GetHWND(winPtr), it crashes from
  winPtr->window being a bad pointer when attempting to
  get winPtr->window.handle.

  After lots of experimentation, I was able to cause the
  crash with a straight wish running the script (as
  opposed to the extended wish plus other Tcl code for my
  application, which originally seemed partly involved
  due to the intermittent nature of the crash) .

  For convenience I've made the buttons take up the huge
  area of the main toplevel (.), but that doesn't matter
  for demonstrating the crash -- it just keeps you from
  having to move the mouse around a bunch.  The crash
  does, however, seem to involve some of the geometry
  operations going on to center and size the various
  windows, combined with the combobox and the window
  icon.  Commenting out any one of these *seems* to stop
  the crash from happening, but since it's intermittent
  it is hard to be sure.  In case it matters, I'm also
  attaching the icon I'm using.

  To demonstrate, after launching the script, click the
  button that says "Combo".  A new toplevel will be
  created, centered on the screen, with a combobox in it.
   Close the window (click the [X] icon).  It seems to
  occur more often if you repeat this (click the "Combo"
  button, close the window that pops up) a couple times.
   Then click exit.  Often, but not always, this will
  crash (with an invalid page fault or an access
  violation depending on whether or not 
  you're running wish from within DevStudio).  After
  rebuilding wish with debugging symbols and running from
  DevStudio I was able to track the crash to the WmProc()
  and Tk_GetHWND().


tkt_uuid: 770578ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: None
title: long text item won't scroll
comment:
  Hi All!

  I am using Tk Canvas for bioinformatic software design
  (multiple alignment visualization).
  I have found one malfunction of long text items --
  if text item is VERY long it scrolling "hangs" when
  scroll displacement reaches ~32000 pixels (I am not sure
  this value is correct).

  I bypassed this bug with splitting text item into
  small chunks (~200 letters).
  Howerever, it's tricky way.

  So, there is my test (tk version is tk-8.3.3-67):

  ############## cut here ##############################
  #!/bin/sh
  # the next line restarts using wish\ 
  exec wish "$0" "$@"

  set longstring [string repeat "bug!_" 10000]
  canvas .c -width 700 -height 50 -xscrollcommand ".s set" \
    -scrollregion "0 0 200000 50"
  scrollbar .s -command ".c xview" -orient horiz
  .c create text 3 10 -anchor w -text $longstring

  pack .c -expand 1 -fill both -side top
  pack .s -expand 1 -fill x -side bottom
  ############## cut here ##############################

  Thanks in advance,
     Dmitry Samborsky, Moscow


tkt_uuid: 775806ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: None
title: text.test fails on Tru64Unix 5.1A
comment:
  Hi,
    The following fails(I have installed current tcl/tk
  from cvs):

  $ ./tktest ../tests/all.tcl -geometry +0+0 -file
  text.test -match text-15.*
  [...]

  ==== text-15.2 TextCmdDeletedProc procedure, disabling
  -setgrid FAILED
  ==== Contents of test case:

      catch {destroy .top}
      toplevel .top
      wm geom .top +0+0
      text .top.t -setgrid 1 -width 20 -height 10
      pack .top.t
      update
      set x [wm geometry .top]
      rename .top.t {}
      update
      lappend x [wm geometry .top]
      destroy .top
      set x

  ---- Result was:
  20x10+0+0 21x11+0+0
  ---- Result should have been (exact matching):
  20x10+0+0 150x140+0+0
  ==== text-15.2 FAILED


tkt_uuid: 776545ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 02. Appearance
priority: 9 Immediate
foundin: TIP Implementation
resolution: Accepted
title: TIP 109 implementation
comment:
  Attached are the patches to apply to 8.5 HEAD versions
  of tkUnixButton.c and tkUnixMenu.c.  These changes
  implement TIP 109.

  -Brian


tkt_uuid: 776646ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 31. Cursor Names
priority: 5 Medium
foundin: None
resolution: Fixed
title: cursor incompatabilities
comment:
  Originally submitted as a Tcl FR by rox - moved to Tk.

   the native pointer in X is "left_ptr" and in windows is
  "arrow". i suggest remapping the cursors so that arrow
  is the native pointer on all platforms

  the fleur/move cursor does not have the native
  appearance in windows

  there is no native hand (hyperlink) cursor spec in
  windows. it should be easy to add a mapping for hand2
  to IDC_HAND.

  the documentation says the "size" cursor is available
  in windows but i got an error when trying to use it in
  my 8.4.2 tclkit.

  all X cursors are available under windows as tk has
  them built in. however the windows cursors are not
  available on other platforms which can cause errors. i
  would suggest mapping the windows cursor names to their
  similar X names when running in X.


tkt_uuid: 777203ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: define TK_INCLUDE_SPEC
comment:
  In Tcl's tclConfig.sh.in file we find:

  # String to pass to the compiler so that an extension can
  # find installed Tcl headers.
  TCL_INCLUDE_SPEC='@TCL_INCLUDE_SPEC@'

  This definition is helpful for extensions of Tcl
  to be able to find tcl.h and other headers.

  It would be similarly helpful to define an
  analogous TK_INCLUDE_SPEC in the
  tkConfig.sh.in file, so that extensions of
  Tk can also reliably find tk.h and other headers.

  The need is most pressing on Mac OS X where
  the custom is apparently not to install these
  headers in $TK_PREFIX/include but instead
  to place them in a "Framework" area.  But it
  would be a handy thing to define on all
  platforms.


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: 778840ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 28. Utility Functions
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: tk::PlaceWindow incorrect for dual-head Windows.
comment:
  The ::tk::PlaceWindow library function doesn't
  understand the geometry reported by Windows for a
  multiple monitor setup. In this situation, the geometry
  for a window position may be negative.

  This has been fixed for BWidgets so it just needs a
  similar fox applying here.


tkt_uuid: 778893ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: None
resolution: Fixed
title: opaqueresize option does nothing
comment:
  The documentation for the panedwindow widget claims
  that the opaqueresize option "Specifies whether panes
  should be resized as a sash is moved (true), or if
  resizing should be deferred until the sash is placed
  (false)."

  In fact, under X and Win32 this option has no effect.
  Examination of the source code shows that this option
  is never used.

  Either the documentation should be fixed or this
  feature should be implemented.


tkt_uuid: 779174ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5a0
resolution: Fixed
title: seg-fault re-using text widget
comment:
  The attached script crashes Tk 8.5a0 when trying to
  re-use the widget name .t.

  NB. The script also crashes Tk 8.4, but that is an
  entirely different crash, in 'destroy .t', which has
  been fixed in 8.5a0.


tkt_uuid: 779559ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 15. [scale]
priority: 3 Low
foundin: obsolete: 8.4.4
resolution: Duplicate
title: scale widget triggering on enter/leave events (LINUX only)
comment:
  The following occurs on LINUX only. I tried many Linux 
  systems with differing O/S versions. All failed. May be a 
  compiler bug, but I'll report and see if anyone else has 
  seen this problem.

  With the -resolution parameter set to a decimal value 
  (.1 for example) , the widget triggers and executes 
  the  -command when the cursor enters and leaves the 
  the slider area (and with tk_strictMotif set, the entire 
  widget).

  The problem appears to be that TkRoundToResolution() 
  returns a value with digits way beyond the end of the 
  specified resolution. Then when -configure events 
  occur, this value is then rounded again producing a 
  slightly different value, so the command is triggered, 
  even though the event was a simple background change 
  as the result of an Enter/Leave event.

  My solution (HACK), was to use the "new" value 
  calculated within TkRoundToResolution() within a dummy 
  print statement. I have no idea why this removes the 
  extra junk, but it does, and the results are that the 
  scale widget works as it should.

  I've attached a two line example which demonstrates 
  the problem. When the example starts, things work as 
  expected, but once the slider has been moved. Moving 
  the cursor thru the slider area triggers the command.


tkt_uuid: 780478ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: None
title: Cascading Menu Problem (OSX - Help SubMenu)
comment:
  We have developed a set of application specific 
  tutorials. This list logically fits very nicely into 
  the Help submenu as a cascading menu.

  This works great under the UNIX and Windows Ports, 
  but the cascading menu does not appear on the OSX 
  port.

  The documentation mentions some restrictions, but not 
  specifically cascading menus. Are these restricted 
  within an "Apple Menu" (whatever that is, they look 
  the same to me)?


tkt_uuid: 780490ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Multi-Line buttons under Mac OSX
comment:
  Multiple line buttons fail on my MacOSX port. The 
  buttons appear to get larger to accomadate the extra 
  lines, but only the first line text will appear.

  The documentation for the button command doesn't 
  suggest any restrictions that I can find.

  Ex.
      pack [button .a -text "Two\nLines"]

  Creates a larger than normal button, but only the
  word "Two" appears (centered).


tkt_uuid: 780528ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: None
resolution: Out of Date
title: radiobuttons without indicators
comment:
  I commonly use radiobuttons with the -indicatoron 
  option set to false. This produces a row of buttons 
  which truely look "old-fashion radio-like", with the 
  current button depressed and all the others popped-up.

  This works wonderfully on UNIX and Windows, but the 
  Mac OSX buttons look the same whether they are up or 
  down.

  Is there no way to change the -relief on a button 
  within Mac OSX?


tkt_uuid: 780536ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: <Control-Alt-Key-Anything> on MacOSX
comment:
  I can not seem to get my Control-Alt sequences 
  working on my Mac OSX port. I "hide" special options 
  on Control-Alt sequences. They work great on our 
  other ports, but I can't make them "fire" on the Mac.

  Alt key seems to generate a Meta KEYSYM and the Apple 
  key seems to generate an Alt KEYSYM. I can work
  with either, but can't get anything to trigger my 
  bindings.

  Ex.

     bind all <Control-Alt-Key-b> "bell"

  Holding Control, Pressing and Holding Alt, and
  pressing the b key should beep once for each time
  the b key is pressed until the Control and/or Alt
  are released. Right?


     


tkt_uuid: 783798ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: None
title: Tcl'2003: lbind
comment:
  Placeholder to remind me about an efficient list and/or
  command-based version of [bind] that I discussed with
  kbk at Tcl2003.  The idea is that it is for a single
  command only and that it only substitutes whole
  arguments to the command.


tkt_uuid: 783802ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 41. Photo Images
priority: 7 High
foundin: None
resolution: None
title: Tcl'2003: Split photo masters into Tcl package
comment:
  One idea that came up at Tcl2003 (in discussion with
  dgp and kbk IIRC) was that the photo master code
  could/should be split off into a separate package that
  can be loaded from Tcl without Tk.  That would prompt
  cleaning up of the grotty colour parsing mechanism, and
  would let images be trivially usable from applications
  like CGI scripts where display access is impractical
  and undesirable.


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: 787402ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: No KP_Enter on Windows
comment:
  Original complaint on comp.lang.tcl:

  From: Wolf Grossi (Go2DevNull@magro-soft.com)
  Subject: KP_Enter on win98se
  Newsgroups: comp.lang.tcl
  Date: 2003-07-03 12:12:46 PST

  Hi all :-)

  can it be true that windoze does not distinguish between
  <Return> and <KP_Enter> ?

  Doing a   bind . <Key>  {puts %K}
  I get
  KP_Enter for enter and
  Return   for return
  on Linux.

  On win98se, the return key and the enter key both give
  <Return> as result.

  I browsed wiki but could not find anything related.

  Any way to solve the puzzle?

  Thanks 4 reading
  Wolf


tkt_uuid: 788069ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Fixed
title: Entry field ignored if -multiple 1 specified
comment:
  On UNIX systems, if the "-multiple 1" option is 
  enabled, typing in the "File Names" entry field does 
  absolutely nothing.

  I patched by changing line 1536 of tkfbox.tcl from:

        if {$data(-multiple)} {

  to:

      if {$data(-multiple) && 
  [::tk::IconList_Curselection $data(icons)] != ""} {

  This "hack" works, but does get the list twice.


tkt_uuid: 788706ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: Fix bind to Alt and Meta modifiers on MacOSX
comment:
  Currently the Command and Option keys can only be bound
  by using their aliases Mod1 and Mod2.

  This patch corrects that by replacing code that tries to
  compute support for these in an X11 fashion (and fails)
  with code that just sets the necessary flags
  unconditionally.  On MacOS all those variations just
  don't exist, so there is no need for the computations.


tkt_uuid: 788825ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 7 High
foundin: obsolete: 8.4.2
resolution: None
title: Tk does not handle non-us primary xkb map properly
comment:
  I had:

  in /etc/X11/XF86Config:
  Section "InputDevice"
    Option       "XkbLayout" "cz_qwerty,us"

  than I run Python's IDLE, that did (using Python-Tk):
  text.event_add("<<calltip-show>>", "(")

  but nothing happend (Czech keyboard has "(" on
  different position) (even if I switched to the
  secondary keymap meanwhile).

  I discovered that it's a problem of a primary xkb map.
  When I change XF86Config to:
  Section "InputDevice"
    Option       "XkbLayout" "us,cz_qwerty"

  it works now.

  I checked other Tk programs and it's broken the same
  way. I guess Tk doesn't use the X events in a proper way...

  Is it understandable? What do you think?

  My e-mail address is: vinil@zagamma.cz. Please, CC me.


tkt_uuid: 788959ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 58. [send]
priority: 6
foundin: TIP Implementation
resolution: Accepted
title: TIP 150: Reference implementation of win32 send
comment:
  This is the implementation of the TIP 150 win32 send
  proposal. This code isn't complete -- it especially
  needs comments adding -- but it is functional.


tkt_uuid: 789272ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 40. Bitmap Images
priority: 8
foundin: obsolete: 8.4.4
resolution: Fixed
title: crash when many bitmaps are used (Windows)
comment:
  On Windows-NT, tk 8.3.3, the following snippet crashes
  wish with a NULL pointer dereference:

  set image [image create bitmap -data \
  {
  #define cross_width 14
  #define cross_height 14
  static char cross_bits[] = {
     0x00, 0x00, 0x00, 0x00, 0x06, 0x18, 0x0e, 0x1c,
  0x1c, 0x0e, 0x38, 0x07,
     0xf0, 0x03, 0xe0, 0x01, 0xe0, 0x01, 0xf0, 0x03,
  0x38, 0x07, 0x1c, 0x0e,
     0x0e, 0x1c, 0x06, 0x18};
  }]

  set maxi 200
  set maxj 62

  for {set i 0} {$i < $maxi} {incr i} {
      for {set j 0} {$j < $maxj} {incr j} {
          grid [button .b$i-$j -image $image] -row $i
  -column $j
      }
  }


  The reason is a failure of CreateBitmap() in
  win/tkWinPixmap.c, #68
      newTwdPtr->bitmap.handle = CreateBitmap(width,
  height, planes, depth, NULL);

  which returns NULL (probably out-of-resources).  This
  is not checked by the calling function, and the
  NULL-Pointer is eventually passed on to
  TkWinGetDrawableDC() which dereferences it.

  I haven't checked by running this in 8.4.4, but from
  looking at the code, the error is not caught there
  either.

  Simply returning NULL im ximage.c does not help, since
  the return-Value of XCreateBitmapFromData() is not
  checked either and simply used.


tkt_uuid: 789889ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 04. Canvas Basics
priority: 3 Low
foundin: None
resolution: Rejected
title: Antialiased Tk Canvas using Cairo
comment:
  Cairo is a vector graphics library which provides,
  among other things, antialiased rendering on X11.  The
  attached patch (supplied by Jeremy Collins -- thanks,
  Jeremy!) adds Cairo support to the Tk canvas.

  See also:
  http://www.tclsource.org/index.adp?page=tk
  http://cairographics.org/


tkt_uuid: 790435ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 02. Appearance
priority: 7 High
foundin: None
resolution: Invalid
title: label redraw issues with images...
comment:
  It seems that labels with images in them (via the -image 
  option) have trouble redrawing (at least on Windows 
  2000) when there are more than a few on the screen.

  I spoke with dkf and he said that this was already 
  a "known issue".


tkt_uuid: 790529ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Out of Date
title: Canvas binding on ButtonRelease destroying canvas crashes
comment:
  The following script:

      proc p {} {
          puts p
          destroy .c
          canvas .c
          grid .c

          .c create rectangle 20 20 40 40 -fill black
  -tags BANG
          .c bind BANG <ButtonRelease> p
      }
      p

  crashes when the black square is clicked.

  Apparently, here is what happens when the binding is
  called:
  - At some point, CanvasDoEvent is called by
  CanvasBindProc, called itself by Tk_HandleEvent; this
  happens at line 4509 in tkCanvas.c
  - CanvasDoEvent eventually interprets the code in proc
  p, which destroys the canvas. This actually destroys
  the canvas at C level: the pointer on it is freed.
  - The next lines of code do mallocs, so the memory
  freed for the canvas pointer gets reused for something else
  - The call from CanvasDoEvent eventually returns and
  CanvasBindProc continues; at this point, the memory
  pointed by canvasPtr is messed up and is not a TkCanvas
  anymore.
  - CanvasBindProc calls PickCurrentItem, which calls
  CanvasFindClosest (tkCanvas.c:4640), which tries to
  browse the items in the canvas via the field
  firstItemPointer, which has been messed up.

  Hence, SEGV or bus error... For some reason, the call
  to PickCurrentItem is explicitely done when the event
  is ButtonRelease. Doing the binding on ButtonPress
  doesn't make the script crash. Another work-around is
  to use the binding:

  .c bind BANG <ButtonRelease> {after idle p}

  The crash always happens on Unices (Linux Mandrake 8.0,
  Solaris 2.6 & 2.7). For some reason, I couldn't get it
  on Windows.


tkt_uuid: 791151ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 02. Appearance
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Improved 3D borders on Unix
comment:
  This patch improves the look of 3D borders by drawing
  them in a more rounded fashion, like Windows.  

  This only affects raised, and sunken borders. 

  For sunken borders it draws the top/left border as
  "darkColor blackColor" and the bottom/right border as
  "bgColor lightColor".

  For raised borders it draws the top/left border as
  "lightColor bgColor" and the bottom/right border as
  "darkColor blackColor".

  To apply:

  cd TK_SRC_DIR
  patch -p1 < tk-unix-3d-borders.patch


tkt_uuid: 791273ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 02. Appearance
priority: 5 Medium
foundin: None
resolution: Accepted
title: Improved 3D borders on Windows
comment:
  This patch ever so slightly tweaks Windows 3D borders
  by flipping the dark and dark2 colors of
  TK_RELIEF_SUNKEN.  This results in the black color
  getting drawn on the inside of the top/left border
  instead of the outside.

  This makes 3D borders appear more like standard Windows
  borders.

  To apply:

  cd $TK_SRC_DIR
  patch -p1 < tk-windows-borders.patch


tkt_uuid: 791292ffffffffffffffffffffffffffffffffff
type: Support
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
title: tip 155 implementation
comment:
  The attached patch makes various changes to the text
  widget, amongst which is a first cut at fixing the
  long-standing inability of the text widget to interact
  correctly with a scrollbar when the text widget
  contains very long wrapped lines.

  More work is still needed, but this basic patch works
  reasonably well for me.

  I'd very interested in comments.

  (Note: the patch also has a first cut implementation of
  a -blockcursor option and a 'replace' subcommand).


tkt_uuid: 791500ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 3 Low
foundin: None
resolution: Fixed
title: PanedWindow refresh glitches on X
comment:
  The panedwindow widget does not set the window
  background; this leads to a display glitch on X when
  the window is exposed.   

  Since there is no window background, the X server
  doesn't clear the newly-exposed area.   Attached patch
  fixes that.


tkt_uuid: 791527ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: None
resolution: None
title: Menubar redisplay glitches on X
comment:
  Most Tk widgets handle <Expose> events by drawing into
  a background pixmap and blitting the results to the
  screen, for a quick refresh.

  The [menu] widget does not; instead it draws directly
  to the window.  This leads to a "blinking" effect when
  e.g., mousing over menu items or keyboard navigation. 
  This is most noticeable on slow displays.


tkt_uuid: 792387ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 8
foundin: obsolete: 8.5a0
resolution: Fixed
title: grid miscalculation
comment:
  The following code

    label .a -text aaa
    label .b -text BbbbB
    label .c -text cccccccccccccccc
    grid .a - - .b
    grid .c - - -
    grid columnconfigure . 1 -weight 1

  creates a window that looks like this

                 aaa     bbb
    cccccccccccccccc

  The .b widget has been truncated but
  should not have been.

  This is with Tk version 8.0.5 on linux.

  Bill Green
  wdkg@umich.edu


tkt_uuid: 792532ffffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: 02. Appearance
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Duplicate
title: wrong stipple-area for "state disabled"
comment:
  since 8.4.3 to current cvs:

  having images on buttons with -borderwidth > 0
  and switching to state disabled, the image isn't
  stippled out completly.  You get an unstippled
  border on the left and on downside. Its size
  depends on borderwidth.

  Example Code:

  set img [image create photo -height 32 -width 32]
  $img put red -to 0 0 31 31
  button .b  \
  -borderwidth 5 \
  -state disabled \
          -image $img 
  pack .b

  Platfomr: Unix + Windows


tkt_uuid: 792554ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 76. Widget Tour
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: Button Inconsistency
comment:
  The "Message boxes" demo (#1 of Common Dialogs) has 
  buttons at the bottom that are inconsistent with the 
  rest of the widget tour (which looks rather nice now!)


tkt_uuid: 793252ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 8
foundin: obsolete: 8.4.4
resolution: Fixed
title: missing var in <ButtonRelease-2> binding
comment:
  Pack a [scale] widget:

  % pack [scale .a -orient horizontal \
                 -resolution .1 \
                 -from -180 -to 180]

  Then click and release mouse button 2
  within the scale.

  Up pops the error message:

  can't read "Priv(.a,relief)": no such element in array.


tkt_uuid: 793825ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 22. Style Engine
priority: 2
foundin: obsolete: 8.5a0
resolution: Wont Fix
title: Style engine crashes
comment:
  Tk_GetStyledElement() can return invalid
  Tk_StyledElements; when calling Tk_DrawElement it
  crashes due to a NULL pointer in
  widgetSpecPtr->elementPtr->specPtr.

  Details sketchy at this point... it seems that this is
  triggered by creating two or more StyledElements with
  different names.


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: 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: 795725ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: Fixed
title: canvas font & foreground
comment:
  Canvas widgets do not support the -font and -foreground
  options. When creating text items, there are given a
  default -fill color of black, which is not very useful
  if the canvas is black. Also text items are given a
  default system-dependent font.

  Of course, if you set resources values such as:

  % option add *Canvas.background black
  % option add *foreground white
  % option add *font "Courier 20"

  this doesn't work. I would like to see the canvas
  widget support these options.

  See also Tk bug report 795717


tkt_uuid: 795869ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 8
foundin: obsolete: 8.4.4
resolution: Fixed
title: panedwindow border overdrawn by child pane
comment:
  From jonathan.bromley@doulos.com

  With more than one pane in a [panedwindow], the 
  last pane is resized when the panedwindow's container
  is resized.  However, if the panedwindow's container
  is shrunk so that the last sash is not visible, panes 
  other than the last are clipped and their contents
  spill over the panedwindow's border, making it
  invisible.  This small example shows the effect
  when the toplevel window is resized manually:

  # silly colours just to make the effect more obvious
  panedwindow .p -borderwidth 5 -background red
  text .p.t1 -bg yellow
  text .p.t2 -bg green
  pack .p -fill both -expand 1
  .p add .p.t1 .p.t2 -sticky news

  Workaround is straightforward but inconvenient:
  give the panedwindow a border width of zero, and
  enclose it in a frame having the desired border.


tkt_uuid: 797404ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 01. Bindings
priority: 9 Immediate
foundin: TIP Implementation
resolution: Accepted
title: Implementation of TIP#158
comment:
  To provide distinction between Return and KP_Enter on
  windows, the following patch does the job:

  Module: tkWinX.c
  Function: GetState

  Immediately following after

  switch(wParam) {
      case VK_SHIFT:
  ...
  }

  1133a1134,1138
  >     if ( HIWORD( lParam ) & KF_EXTENDED ) {
  >        mask |= Mod4Mask;   
  >        prevState = ((state & mask) ^ prevState) ? 0 : 1;
  >     }
  >

  KP_Enter is recognized as Mod4-Return if bound.
  Otherwise, KP_Enter is recognized as Return.


   


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: 800139ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 74. Application Embedding
priority: 5 Medium
foundin: TIP Implementation
resolution: Accepted
title: TIP 137: -encoding option for wish, etc.
comment:
  Here's a patch that implements
  the Tk portion of TIP 137 (as
  modified by TIP 151).  It adds
  a -encoding command line
  option to wish, and to other
  applications that use
  Tk_MainEx() as their main 
  procedure.


tkt_uuid: 800149ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.5a1
resolution: Duplicate
title: Memory leaks with --enable-xft
comment:
  Just ran wish under valgrind, and saw a lot of
  unfree()d memory allocated from within libXft.  (This
  is almost certainly due to Tk's use of libXft, not
  libXft itself.)

  Reminder to examine this in detail later.


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: 800370ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Duplicate
title: Arc item with coordinate list does not handle options
comment:
  The following script produces an error:

  canvas .c 
  pack .c -fill both
  .c create arc {10 10 100 100} -start 0 -extent 180 

  The error message is:
  unknown option "180"

  When you leave out the braces, all is well.


tkt_uuid: 800419ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 9 Immediate
foundin: obsolete: 8.5a0
resolution: None
title: wish crashes on startup (dbg, thrd, thrdalloc)...
comment:
  After some investigation, I believe I sorta know what is 
  causing this to happen.

  The code in TclDbInitNewObj (line 538) expects that the 
  call to Tcl_CreateHashEntry will create a new entry to 
  track that block of memory.  However, TclpAlloc (the 
  one in tclThreadAlloc.c, line 301) is apparently returning 
  a previously used block to Tcl_DbCkalloc, which causes 
  TclDbInitNewObj to fail.  

  Here is the stack trace:

  Tcl_PanicVA(const char * 0x100cd344, char * 
  0x0012a42c) line 97 + 42 bytes
  Tcl_Panic(const char * 0x100cd344) line 134 + 13 bytes
  TclDbInitNewObj(Tcl_Obj * 0x00ad51d0) line 540 + 10 
  bytes
  Tcl_DbNewStringObj(const char * 0x009a4198, int 62, 
  const char * 0x100b8348, int 4618) line 267 + 45 bytes
  Tcl_AddObjErrorInfo(Tcl_Interp * 0x0086ade8, const 
  char * 0x0012a468, int -1) line 4618 + 25 bytes
  Tcl_LogCommandInfo(Tcl_Interp * 0x0086ade8, const 
  char * 0x00af57d8, const char * 0x00af5d14, int 38) 
  line 3325 + 18 bytes
  TclExecuteByteCode(Tcl_Interp * 0x0086ade8, 
  ByteCode * 0x00aba320) line 4134 + 27 bytes
  TclCompEvalObj(Tcl_Interp * 0x0086ade8, Tcl_Obj * 
  0x00add9a8) line 986 + 13 bytes
  TclObjInterpProc(void * 0x00af0548, Tcl_Interp * 
  0x0086ade8, int 1, Tcl_Obj * const * 0x0012b29c) line 
  1080 + 19 bytes
  TclEvalObjvInternal(Tcl_Interp * 0x0086ade8, int 1, 
  Tcl_Obj * const * 0x0012b29c, const char * 
  0x00ab8d57, int 13, int 0) line 3095 + 25 bytes
  Tcl_EvalEx(Tcl_Interp * 0x0086ade8, const char * 
  0x00ab5b58, int 12812, int 0) line 3525 + 36 bytes
  Tcl_FSEvalFile(Tcl_Interp * 0x0086ade8, Tcl_Obj * 
  0x00a8dbe8) line 1445 + 19 bytes
  Tcl_SourceObjCmd(void * 0x00000000, Tcl_Interp * 
  0x0086ade8, int 2, Tcl_Obj * const * 0x0012b654) line 
  1012 + 16 bytes
  TclEvalObjvInternal(Tcl_Interp * 0x0086ade8, int 2, 
  Tcl_Obj * const * 0x0012b654, const char * 
  0x00aa5070, int 56, int 0) line 3095 + 25 bytes
  Tcl_EvalEx(Tcl_Interp * 0x0086ade8, const char * 
  0x00aa5070, int 56, int 0) line 3525 + 36 bytes
  Tcl_Eval(Tcl_Interp * 0x0086ade8, const char * 
  0x00aa5070) line 3629 + 17 bytes
  Tcl_GlobalEval(Tcl_Interp * 0x0086ade8, const char * 
  0x00aa5070) line 4756 + 13 bytes
  Tcl_PkgRequireEx(Tcl_Interp * 0x0086ade8, const char 
  * 0x00a67608, const char * 0x00000000, int 0, void * * 
  0x00000000) line 312 + 16 bytes
  Tcl_PkgRequire(Tcl_Interp * 0x0086ade8, const char * 
  0x00a67608, const char * 0x00000000, int 0) line 164 + 
  23 bytes
  Tcl_PackageObjCmd(void * 0x00000000, Tcl_Interp * 
  0x0086ade8, int 3, Tcl_Obj * const * 0x009800dc) line 
  718 + 21 bytes
  TclEvalObjvInternal(Tcl_Interp * 0x0086ade8, int 3, 
  Tcl_Obj * const * 0x009800dc, const char * 
  0x00000000, int 0, int 0) line 3095 + 25 bytes
  TclExecuteByteCode(Tcl_Interp * 0x0086ade8, 
  ByteCode * 0x00a35868) line 1407 + 36 bytes
  TclCompEvalObj(Tcl_Interp * 0x0086ade8, Tcl_Obj * 
  0x00a29590) line 986 + 13 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x0086ade8, Tcl_Obj * 
  0x00a29590, int 0) line 3759 + 13 bytes
  NamespaceEvalCmd(void * 0x00000000, Tcl_Interp * 
  0x0086ade8, int 4, Tcl_Obj * const * 0x009800c8) line 
  2976 + 18 bytes
  Tcl_NamespaceObjCmd(void * 0x00000000, Tcl_Interp * 
  0x0086ade8, int 4, Tcl_Obj * const * 0x009800c8) line 
  2529 + 21 bytes
  TclEvalObjvInternal(Tcl_Interp * 0x0086ade8, int 4, 
  Tcl_Obj * const * 0x009800c8, const char * 
  0x00000000, int 0, int 0) line 3095 + 25 bytes
  TclExecuteByteCode(Tcl_Interp * 0x0086ade8, 
  ByteCode * 0x00a1e0b8) line 1407 + 36 bytes
  TclCompEvalObj(Tcl_Interp * 0x0086ade8, Tcl_Obj * 
  0x00a81c10) line 986 + 13 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x0086ade8, Tcl_Obj * 
  0x00a81c10, int 0) line 3759 + 13 bytes
  NamespaceEvalCmd(void * 0x00000000, Tcl_Interp * 
  0x0086ade8, int 4, Tcl_Obj * const * 0x0012cf30) line 
  2976 + 18 bytes
  Tcl_NamespaceObjCmd(void * 0x00000000, Tcl_Interp * 
  0x0086ade8, int 4, Tcl_Obj * const * 0x0012cf30) line 
  2529 + 21 bytes
  TclEvalObjvInternal(Tcl_Interp * 0x0086ade8, int 4, 
  Tcl_Obj * const * 0x0012cf30, const char * 
  0x00a90246, int 982, int 0) line 3095 + 25 bytes
  Tcl_EvalEx(Tcl_Interp * 0x0086ade8, const char * 
  0x00a8ffb0, int 17577, int 0) line 3525 + 36 bytes
  Tcl_FSEvalFile(Tcl_Interp * 0x0086ade8, Tcl_Obj * 
  0x00a81190) line 1445 + 19 bytes
  Tcl_SourceObjCmd(void * 0x00000000, Tcl_Interp * 
  0x0086ade8, int 2, Tcl_Obj * const * 0x00a67708) line 
  1012 + 16 bytes
  TclEvalObjvInternal(Tcl_Interp * 0x0086ade8, int 2, 
  Tcl_Obj * const * 0x00a67708, const char * 
  0x100da7da, int 0, int 262144) line 3095 + 25 bytes
  Tcl_EvalObjv(Tcl_Interp * 0x0086ade8, int 2, Tcl_Obj * 
  const * 0x00a67708, int 262144) line 3206 + 32 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x0086ade8, Tcl_Obj * 
  0x00a81f90, int 262144) line 3744 + 27 bytes
  Tcl_UplevelObjCmd(void * 0x00000000, Tcl_Interp * 
  0x0086ade8, int 1, Tcl_Obj * const * 0x009800c4) line 
  674 + 20 bytes
  TclEvalObjvInternal(Tcl_Interp * 0x0086ade8, int 3, 
  Tcl_Obj * const * 0x009800bc, const char * 
  0x00000000, int 0, int 0) line 3095 + 25 bytes
  TclExecuteByteCode(Tcl_Interp * 0x0086ade8, 
  ByteCode * 0x00a80090) line 1407 + 36 bytes
  TclCompEvalObj(Tcl_Interp * 0x0086ade8, Tcl_Obj * 
  0x00a6c610) line 986 + 13 bytes
  TclObjInterpProc(void * 0x00a62c00, Tcl_Interp * 
  0x0086ade8, int 7, Tcl_Obj * const * 0x00a22d00) line 
  1080 + 19 bytes
  TclEvalObjvInternal(Tcl_Interp * 0x0086ade8, int 7, 
  Tcl_Obj * const * 0x00a22d00, const char * 
  0x100da7da, int 0, int 262144) line 3095 + 25 bytes
  Tcl_EvalObjv(Tcl_Interp * 0x0086ade8, int 7, Tcl_Obj * 
  const * 0x00a22d00, int 262144) line 3206 + 32 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x0086ade8, Tcl_Obj * 
  0x009c7588, int 262144) line 3744 + 27 bytes
  Tcl_UplevelObjCmd(void * 0x00000000, Tcl_Interp * 
  0x0086ade8, int 1, Tcl_Obj * const * 0x009800b8) line 
  674 + 20 bytes
  TclEvalObjvInternal(Tcl_Interp * 0x0086ade8, int 3, 
  Tcl_Obj * const * 0x009800b0, const char * 
  0x00000000, int 0, int 0) line 3095 + 25 bytes
  TclExecuteByteCode(Tcl_Interp * 0x0086ade8, 
  ByteCode * 0x00a3b430) line 1407 + 36 bytes
  TclCompEvalObj(Tcl_Interp * 0x0086ade8, Tcl_Obj * 
  0x009c7f88) line 986 + 13 bytes
  TclObjInterpProc(void * 0x009c7f08, Tcl_Interp * 
  0x0086ade8, int 8, Tcl_Obj * const * 0x00a29790) line 
  1080 + 19 bytes
  TclEvalObjvInternal(Tcl_Interp * 0x0086ade8, int 8, 
  Tcl_Obj * const * 0x00a29790, const char * 
  0x00000000, int 0, int 0) line 3095 + 25 bytes
  TclEvalObjvInternal(Tcl_Interp * 0x0086ade8, int 7, 
  Tcl_Obj * const * 0x00980094, const char * 
  0x00000000, int 0, int 0) line 3047 + 30 bytes
  TclExecuteByteCode(Tcl_Interp * 0x0086ade8, 
  ByteCode * 0x00a17c28) line 1407 + 36 bytes
  TclCompEvalObj(Tcl_Interp * 0x0086ade8, Tcl_Obj * 
  0x009991c0) line 986 + 13 bytes
  TclObjInterpProc(void * 0x0099e308, Tcl_Interp * 
  0x0086ade8, int 1, Tcl_Obj * const * 0x0012f9e4) line 
  1080 + 19 bytes
  TclEvalObjvInternal(Tcl_Interp * 0x0086ade8, int 1, 
  Tcl_Obj * const * 0x0012f9e4, const char * 
  0x002f333c, int 6, int 0) line 3095 + 25 bytes
  Tcl_EvalEx(Tcl_Interp * 0x0086ade8, const char * 
  0x002f3270 initScript, int 210, int 0) line 3525 + 36 bytes
  Tcl_Eval(Tcl_Interp * 0x0086ade8, const char * 
  0x002f3270 initScript) line 3629 + 17 bytes
  TkpInit(Tcl_Interp * 0x0086ade8) line 51 + 21 bytes
  Initialize(Tcl_Interp * 0x0086ade8) line 3164 + 9 bytes
  Tk_Init(Tcl_Interp * 0x0086ade8) line 2804 + 9 bytes
  Tcl_AppInit(Tcl_Interp * 0x0086ade8) line 161 + 10 
  bytes
  Tk_MainEx(int 1, char * * 0x00866e20, int (Tcl_Interp *)
  * 0x004010b9 Tcl_AppInit(Tcl_Interp *), Tcl_Interp * 
  0x0086ade8) line 222 + 7 bytes
  WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 
  0x00000000, char * 0x0013374d, int 1) line 130 + 26 
  bytes
  WinMainCRTStartup() line 330 + 54 bytes
  KERNEL32! GetProcessPriorityBoost + 279 bytes


tkt_uuid: 801001ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 50. [pack]
priority: 1 Zero
foundin: obsolete: 8.4.4
resolution: Out of Date
title: Portability issue -- writing over/under resize handle
comment:
  Shouldn't packer be aware that the lower right corner of 
  the window is reserved for the resize handle and avoid 
  putting non-empty frames in that corner of the window?


tkt_uuid: 801011ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: None
resolution: Rejected
title: Wish should remain resident
comment:
  Wish should remain resident on Mac OS X. There's a fairly 
  significant startup overhead for Aqua applications, and on 
  my G3/400 it takes several seconds to launch. This makes 
  it too "heavy" for casual applications (for example, in 
  OnMyCommand scripts). Running a "Wish" in the 
  background doesn't help, because it launches a separate 
  instance for each application.


tkt_uuid: 802296ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: transparent backgrounds
comment:
  Hi,
  I'm a developper in the aMSN's project (amsn.sf.net) and we would 
  like a new feature but it looks pretty hard to add.. it's about skinning, 
  we want to create skins, which means we need two new things, first a 
  [wm border borderless] command that would tell the window manager 
  to disable border (so we can create our own title bar and close icons 
  with our own images) .. but that's not really *important* ...
  The second request is more important.. we would like to make a 
  background image for text widgets (chat windows or for the main 
  contact list window) I thought about doing something like pack $w.
  text -in $w.label (with a label -image ... ) but I noticed that the image 
  disappears behind the text widget... so the text widget background is 
  solid... what would help us alot, is having a transparent background... 
  only the text and windows/images added in the text widget would be 
  solid... that could be a new option (-backgroundimage) or with 
  -background transparent ... or maybe juste set a color that would be 
  transparent like -background #-1-1-1 ....
  anyways I would like your advice on this, are you going to add this 
  soon, or maybe there is some other way to do what I am requesting..
  .

  KaKaRoTo


tkt_uuid: 802435ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 7 High
foundin: None
resolution: Fixed
title: memory leak in tkConsole.c...
comment:
  The file generic/tkConsole.c has a memory leak in 
  function ConsoleEventProc.

  Near line 748, the following is allocated:

  Tcl_DStringInit(&dString);

  Near line 759, there is a return statement that does not 
  free the memory:

          if (consoleInterp == (Tcl_Interp *) NULL) {
              return;
          }

  I believe the code should be changed to:

          if (consoleInterp == (Tcl_Interp *) NULL) {
              Tcl_DStringFree(&dString);
              return;
          }


tkt_uuid: 802445ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Out of Date
title: bogus "image create" command crashes wish
comment:
  Running the following one-liner script crashes wish
  % image create photo .

  Here's a traceback from within gdb:
  #0  0x080de37d in ?? ()
  #1  0x4009a77d in Tk_ImageObjCmd () from
  /usr/lib/libtk8.3.so
  #2  0x4010e5b5 in TclExecuteByteCode () from
  /usr/lib/libtcl8.3.so
  #3  0x400f2233 in Tcl_EvalObjEx () from
  /usr/lib/libtcl8.3.so
  #4  0x401180a5 in Tcl_RecordAndEvalObj () from
  /usr/lib/libtcl8.3.so
  #5  0x40117f82 in Tcl_RecordAndEval () from
  /usr/lib/libtcl8.3.so
  #6  0x40045b54 in Tk_MainEx () from /usr/lib/libtk8.3.so
  #7  0x4011f8b0 in Tcl_NotifyChannel () from
  /usr/lib/libtcl8.3.so
  #8  0x40147fb9 in Tcl_DeleteFileHandler () from
  /usr/lib/libtcl8.3.so
  #9  0x4012b00d in Tcl_ServiceEvent () from
  /usr/lib/libtcl8.3.so
  #10 0x4012b335 in Tcl_DoOneEvent () from
  /usr/lib/libtcl8.3.so
  #11 0x40039f1f in Tk_MainLoop () from /usr/lib/libtk8.3.so
  #12 0x400459b4 in Tk_MainEx () from /usr/lib/libtk8.3.so
  #13 0x08048854 in main ()
  #14 0x42015574 in __libc_start_main () from
  /lib/tls/libc.so.6

  This is probably the cause of this Tkinter bug:
  python.org/sf/802417


tkt_uuid: 803060ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 39. Image Basics
priority: 5 Medium
foundin: None
resolution: Accepted
title: Enhance the man page
comment:
  Please add another section to the image man page:

     [start of text]
  Additional image commands
  --------------------------
  Additional opearations (e.g. configure, read, write)
  may be available for different image types. See the
  respective manual entries (bitmap, photo) for more
  information.
     [end of text]

  Rational: Could well be, this seems obvious to anybody
  familiar with the (internal) structure of Tk's handling
  of images:
  - top level: [image] command
  - inermediate: type handler (e.g. photo)
  - low-level: specific formats (e.g. gif) in the Img
  extension

  Not being familiar with it, I spent a lot of time
  searching at the top (image) and the bottom (Img::gif)
  for information on how to save an image to file. The
  proposed addition might help the next guy save some time.

  Best regards
  Helmut Giese


tkt_uuid: 805091ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: Fixed
title: tab filename completion in file dialogs
comment:
  Idea:

  Gtk file dialogs have a feature that I like, being a
  unix guy used to using tab to complete everything.  In
  the file dialog entry widgets, you can do tab
  completion with tab untill the name is complete.  At
  that point tab will take you to the next widget, as
  usual.  I would find this handy in the Tk file dialogs too.


tkt_uuid: 805957ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 51. [place]
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Invalid
title: error in label sizing...
comment:
  The following script does not work as expected:

  canvas .canvas -background "red" -borderwidth "0" -
  highlightthickness "0" -width "800" -height "600"
  label .canvas.thisLabel -background "blue" -
  borderwidth "0" -highlightthickness "0" -width "200" -
  height "95"
  place .canvas -in . -x 0 -y 0
  place .canvas.thisLabel -in .canvas -x 0 -y 0

  Unless I am reading the Tk docs wrong (it's 5:30am), 
  this script should produce a canvas that is 800 by 600 
  pixels in size inside the toplevel window with a red 
  background. It should also produce a label of 200 by 95 
  pixels in size inside the canvas.  Upon running this script 
  using Tcl/Tk 8.4.4 (ActiveState build), the label appears 
  to take up the entire width and height of the parent.

  I believe this is a bug.


tkt_uuid: 806807ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: Fixed
title: User data in virtual events
comment:
  It'd be sometimes extremely useful to be able to pass
  some user-supplied data in virtual events.  This is
  because there is often some extra information that
  doesn't fit the basic model that would still make
  sense.  It also has no significant resource management
  problems since the string would only ever be passed
  about within the process.


tkt_uuid: 808039ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Fixed
title: [image create] generates used command names
comment:
  Interactive wish session:

  % proc image1 {} {puts foo}
  % image create bitmap
  image1
  % image1
  wrong # args: should be "image1 option ?arg arg ...?"

  The original programmer's [image1] command 
  is lost because of a conflict with an artbitrary name
  generated by [image create].  Since [image create]
  does not even document what names it generates,
  there no 100% way for the paranoid programmer to
  avoid this nastiness (other than not use [image]).

  A policy of overwriting may make sense when the
  programmer provides the image command name, but
  it seems that [image create] should keep generating
  names until it finds on that does not conflict.

  Seems like a bug to me.  If the maintainer disagrees,
  I'd like to know why.


tkt_uuid: 809157ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 41. Photo Images
priority: 4
foundin: obsolete: 8.4.4
resolution: Accepted
title: partially transparent images don't display correctly.
comment:
  When using "partial transparency of images with non-
  trivial alpha channels", the renderer always assumes a 
  grey background. This means that if the image has any 
  areas that are partially transparent instead of fully 
  transparent they will be rendered as grey pixels. This 
  precludes using any shape such as a rounded edge, 
  circles, ovals, triangles, polygons, etc (anything other 
  than a normalized, non-rotated rectangle) that require 
  anti-aliasing in an image as the edges will appear jagged 
  with grey pixels instead of smooth and blended with the 
  background pixels. The correct behaviour is to instead 
  sample the underlying background pixel and combine it 
  with the partially transparent pixel of the foreground 
  image to create a new "result" pixel. According to dkf 
  the issue appears to be a bug in the renderer code 
  in "tkImgPhoto.c".


tkt_uuid: 810026ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Remind
title: TkAqua: handle resolution independent UI in Tiger+
comment:
  In Mac OS X Aqua, Tk assumes 72 DPI resolution.  Many 
  macs have higher resolution, though.  This patch correctly 
  finds the screen size, and thereby the correct tk scaling.


tkt_uuid: 812415ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: wm stackorder causes wish to crash
comment:
  Test sequence:

  launch wish (Aqua-Tk)

  % toplevel .t
  % wm stackorder .

  wish crashes.

  Reproduced on a fresh TclTk8.4.4 install (from sourceforge / 
  Daniel's distribution).

  Works fine on Mac OS X - X11 and on windows 2k.

  Discussed on the tcl-mac mailing list:

  http://sourceforge.net/mailarchive/forum.php?forum=tcl-
  mac


tkt_uuid: 813945ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 44. Generic Fonts
priority: 7 High
foundin: None
resolution: None
title: [font height] command to measure height of text string...
comment:
  [font height] command that accurately measures the 
  height of a text string (even one that contains multiple 
  lines).  Please see the attached patch for more 
  information.


tkt_uuid: 814609ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 58. [send]
priority: 7 High
foundin: obsolete: 8.5a0
resolution: None
title: tip150 breaks lots of tests
comment:
  TIP 150 was applied, but apparently no tests were
  updated.  Quite a few fail (this is on WinXP). 
  Shouldn't the tests have been run *before* applying the
  patch *grin*:

  Only running test files that match:  s*
  Tests began at Mon Sep 29 19:15:11 GMT Daylight Time 2003
  safe.test

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

      catch {safe::interpDelete a}
      safe::interpCreate a
      safe::loadTk a
      set l [lsort [interp hidden a]]
      safe::interpDelete a
      set l

  ---- Result was:
  bell cd clipboard encoding exec exit fconfigure file
  glob grab load menu open pw
  d selection send socket source tk_chooseColor
  tk_chooseDirectory tk_getOpenFile
  tk_getSaveFile tk_messageBox toplevel wm
  ---- Result should have been (exact matching):
  bell cd clipboard encoding exec exit fconfigure file
  glob grab load menu open pw
  d selection socket source tk_chooseColor
  tk_chooseDirectory tk_getOpenFile tk_ge
  tSaveFile tk_messageBox toplevel wm
  ==== safe-1.2 FAILED

  scale.test
  scrollbar.test
  select.test
  send.test

  ==== send-8.1 Tk_SendCmd procedure, options FAILED
  ==== Contents of test case:

      setupbg
      set app [dobg {tk appname}]
      set a 66
      send -async $app [list send [tk appname] set a 77]
      set result $a
      after 200 set x 40
      tkwait variable x
      cleanupbg
      lappend result $a

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== send-8.1 FAILED


  ==== send-8.4 Tk_SendCmd procedure, options FAILED
  ==== Contents of test case:

      list [catch {send -gorp foo bar baz} msg] $msg

  ---- Result was:
  1 {no application named "-gorp"}
  ---- Result should have been (exact matching):
  1 {bad option "-gorp": must be -async, -displayof, or --}
  ==== send-8.4 FAILED


  ==== send-8.5 Tk_SendCmd procedure, options FAILED
  ==== Contents of test case:

      list [catch {send -async foo} msg] $msg

  ---- Result was:
  1 {bad option "foo": must be -async, -displayof, or
  --wrong # args: should be "s
  end ?-async? ?-displayof? ?--? interpName arg ?arg ...?"}
  ---- Result should have been (exact matching):
  1 {wrong # args: should be "send ?options? interpName
  arg ?arg ...?"}
  ==== send-8.5 FAILED


  ==== send-8.6 Tk_SendCmd procedure, options FAILED
  ==== Contents of test case:

      list [catch {send foo} msg] $msg

  ---- Result was:
  1 {bad option "foo": must be -async, -displayof, or
  --wrong # args: should be "s
  end ?-async? ?-displayof? ?--? interpName arg ?arg ...?"}
  ---- Result should have been (exact matching):
  1 {wrong # args: should be "send ?options? interpName
  arg ?arg ...?"}
  ==== send-8.6 FAILED


  ==== send-8.9 Tk_SendCmd procedure, local execution FAILED
  ==== Contents of test case:

      set a initial
      string tolower [list [catch {send [tk appname] open
  bad_file} msg]  $msg $er
  rorInfo $errorCode]

  ---- Result was:
  1 {couldn't open "bad_file": no such file or directory}
  {couldn't open "bad_file
  ": no such file or directory
      while executing
  "open bad_file"enoent
      invoked from within
  "send [tk appname] open bad_file"} posix
  ---- Result should have been (exact matching):
  1 {couldn't open "bad_file": no such file or directory}
  {couldn't open "bad_file
  ": no such file or directory
      while executing
  "open bad_file"
      invoked from within
  "send [tk appname] open bad_file"} {posix enoent {no
  such file or directory}}
  ==== send-8.9 FAILED


  ==== send-8.18 Tk_SendCmd procedure, error in remote
  app FAILED
  ==== Contents of test case:

      setupbg
      set app [dobg {tk appname}]
      set result [string tolower [list [catch {send $app
  open bad_name} msg]  $msg
   $errorInfo $errorCode]]
      cleanupbg
      set result

  ---- Result was:
  1 {no application named ""} {no application named ""
      while executing
  "send $app open bad_name"} none
  ---- Result should have been (exact matching):
  1 {couldn't open "bad_name": no such file or directory}
  {couldn't open "bad_name
  ": no such file or directory
      while executing
  "open bad_name"
      invoked from within
  "send $app open bad_name"} {posix enoent {no such file
  or directory}}
  ==== send-8.18 FAILED


  ==== send-8.19 Tk_SendCmd, using modal timeouts FAILED
  ==== Contents of test case:

      setupbg
      set app [dobg {tk appname}]
      set x no
      set result ""
      after 0 {set x yes}
      lappend result [send $app {concat x y z}]
      lappend result $x
      update
      cleanupbg
      lappend result $x

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ==== send-8.19 FAILED


  ==== send-12.2 TimeoutProc procedure FAILED
  ==== Contents of test case:

      winfo interps
      tk appname tktest
      update
      setupbg
      set app [dobg {
          after 10 {after 10 {after 5000; exit}}
          tk appname
      }]
      after 200
      set result [list [catch {send $app foo} msg] $msg]
      cleanupbg
      set result

  ---- Result was:
  1 {no application named ""}
  ---- Result should have been (exact matching):
  1 {target application died}
  ==== send-12.2 FAILED


  ==== send-13.1 DeleteProc procedure FAILED
  ==== Contents of test case:

      setupbg
      set app [dobg {rename send {}; tk appname}]
      set result [list [catch {send $app foo} msg] $msg
  [winfo interps]]
      cleanupbg
      set result

  ---- Result was:
  1 {no application named ""} {tktest {tk #2} script tk}
  ---- Result should have been (exact matching):
  1 {no application named "tktest #2"} tktest
  ==== send-13.1 FAILED


  ==== send-13.2 DeleteProc procedure FAILED
  ==== Contents of test case:

      winfo interps
      tk appname tktest
      rename send {}
      set result {}
      lappend result [winfo interps] [info commands send]
      tk appname foo
      lappend result [winfo interps] [info commands send]

  ---- Result was:
  {script tk} {} {foo script tk} send
  ---- Result should have been (exact matching):
  {} {} foo send
  ==== send-13.2 FAILED

  spinbox.test

  Tests ended at Mon Sep 29 19:15:24 GMT Daylight Time 2003
  all.tcl:        Total   860     Passed  677     Skipped
  172     Failed  11
  Sourced 12 Test Files.
  Files with failing tests: safe.test send.test
  Number of tests skipped for each constraint:
          7       altDisplay
          35      fonts
          1       knownBug
          10      macOnly
          13      macOrUnix
          8       nonPortable
          54      testsend
          44      unixOnly
  stderr32
  C:\Programming\Tcl-source\cvs-tk\win>
  C:\Programming\Tcl-source\cvs-tk\win>


tkt_uuid: 814762ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Out of Date
title: Button clips text, Mac Aqua
comment:
  Buttons in the Aqua version of Tk 8.4.4 are made too small
  for the text, clipping the left and right letters of
  the text,
  when padx = 0.  This is on Mac OS 10.2.6.

  The following Wish 8.4.4 script

  button .b -padx 0 -text {some text}
  pack .b

  displays a button with only "ome te" visible.


tkt_uuid: 814788ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Out of Date
title: No multi-line Button text, Mac Aqua
comment:
  In Aqua Tk 8.4.4 only the first line of text is shown
  in a Button
  set to show two lines of text.  The following wish script

  button .b -text "some
  text"
  pack .b

  produces a button showing just the word "some".

  On Linux, Windows, SGI Irix and HP Alpha systems Tk
  8.4.4 shows both lines in the button.


tkt_uuid: 814792ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Out of Date
title: Wrapped checkbutton text is clipped
comment:
  If checkbutton text wraps onto 2 lines in Aqua Tk 8.4.4
  then it
  is clipped on the top and bottom because not enough
  vertical
  space is allocated.  The following example,

  wm geometry . 400x100
  checkbutton .b -text {Some long text that wraps onto
  two lines to show the vertical clipping problem}
  pack .b

  wraps the checkbutton text onto 2 lines.  The tops of
  the characters
  in the first line are not visible and the bottom of the
  characters on
  the second line are not visible.


tkt_uuid: 814810ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 7 High
foundin: obsolete: 8.4.4
resolution: Fixed
title: Update idletasks does not redraw labels, Mac Aqua
comment:
  The "update idletasks" command does not redraw changed
  label
  text in Aqua Tk 8.4.4.  Although this is not required
  behaviour it
  is the suggested use of "update idletasks" described in
  the Tcl
  update manual page.

  "If the idletasks keyword is specified as an argument
  to the command, then no new events or errors are
  processed; only idle callbacks are invoked. This causes
  operations that are normally deferred, such as display
  updates and window layout calculations, to be performed
  immediately.

  The update idletasks command is useful in scripts where
  changes have been made to the application's state and
  you want those changes to appear on the display
  immediately, rather than waiting for the script to
  complete. Most display updates are performed as idle
  callbacks, so update idletasks will cause them to run."

  The following example,

  label .l -text "hello"
  .l configure -text {making progress} ; update idletasks
  ; for {set i 0} {$i<10000000} {incr i} {}

  does not redraw the label under Aqua Tk until after the
  for loop
  terminates.  On Linux, Windows, SGI and HP Alpha the redraw
  occurs before the for loop terminates.  We use "update
  idletasks"
  to provide progress messages during time consuming
  operations.


tkt_uuid: 814831ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Out of Date
title: No flat button relief, Mac Aqua
comment:
  Setting relief to "flat" makes no difference in Aqua Tk
  8.4.4.
  The button still appears raised.

  button .b -relief flat -text {hippo}
  pack .b

  The Python Mega-Widget package uses flat relief buttons
  for the
  tabs on tabbed panes (PMW Notebook).  The raised buttons
  make it not obvious these are tabs.

  This is related to tktoolkit bug 780528 which is a
  relief problem
  with radiobuttons with indicators off.


tkt_uuid: 814844ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Out of Date
title: No multi-column menus, Mac Aqua
comment:
  Multi-column menus are displayed as a single column in
  Aqua Tk 8.4.4.  The following example,

  menubutton .b -text Tools
  menu .b.m
  .b.m add command -label stuff
  .b.m add command -label more -columnbreak 1
  .b configure -menu .b.m
  pack .b

  produces a single column menu using Aqua Tk.  On Linux,
  Windows, SGI and HP Alpha it makes a 2 column menu.

  In our application the second column has checkbuttons
  with the
  last one being "all of the above".  The meaning of this
  becomes
  confusing when all entries are displayed in one column.


tkt_uuid: 814846ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 3 Low
foundin: obsolete: 8.5.8
resolution: Out of Date
title: No menu entry background color, Mac Cocoa
comment:
  Setting background colors for menu entries in Aqua Tk
  8.4.4 has
  no effect.  Here's an example.

  menubutton .b -text Tools
  menu .b.m
  .b.m add command -label stuff -background red
  .b configure -menu .b.m
  pack .b

  The resulting menu has a white background on the Mac.
  On Linux, Windows, SGI and HP Alpha the menu entry
  background comes out red as requested.


tkt_uuid: 815118ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 76. Widget Tour
priority: 5 Medium
foundin: None
resolution: Fixed
title: package require Tk addition
comment:
  now that Tk is a loadable package, it would be useful
  to add the
  package require statement to the various demos.  In
  that way, people
  could be using tclsh or tclkit to run the demos, and Tk
  would be 
  loaded as appropriate.


tkt_uuid: 815751ffffffffffffffffffffffffffffffffff
type: Support
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
title: TIP 159 Reference implementation
comment:
  This patch implements the Unix portion of
  TIP 159 (EXTENDING TK 'WM' COMMAND TO SUPPORT COLOURED
  ICONS)


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: 818489ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Fixed
title: Incorrect image on disabled button
comment:
  Using Tk-8.4.4 on HP-UX11i, buttons displaying an image 
  are not correctly shown when the button is disabled 
  (unless disabledforeground' is set to an empty string).

  The stipple is offset several pixels to the northeast.

  The attached file contains 'button.tcl' example 
  code, 'square.xbm' example bitmap and 'dump.tif' - 
  screen dump from HP-UX.

  This was originally observed using Python 2.3 + Tkinter + 
  Tk-8.4.4 on both HP-UX and Windows 2000. It doesn't 
  happen on Linux.

  It also happens with Tk-8.4.3, but not with Tk-8.3.4.


tkt_uuid: 819284ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 3 Low
foundin: obsolete: 8.3b1
resolution: Fixed
title: ::tk::PlaceWindow is wrong
comment:
  ::tk::PlaceWindow is wrong
  # ::tk::PlaceWindow --
  # place a toplevel at a particular position
  # Arguments:
  # toplevel name of toplevel window
  # ?placement? pointer ?center? ; places $w centered
  on the pointer
  # widget widgetPath ; centers $w over
  widget_name
  # defaults to placing toplevel in the
  middle of the screen

  ^^^^^^^^^^^^^^^ BUG

  # ?anchor? center or widgetPath
  # Results:
  # Returns nothing
  #

  => this is wrong because the condition fails ....

  a) first condition .....
  [string equal -len [string length $place] $place
  "pointer"]
  thist ist true for $place == "" => the default ....
  => pointerplacement ist the default and !not! the
  middle of
  the screen

  mfg

  aotto


tkt_uuid: 819290ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: None
resolution: None
title: tk_messageBox -timeout option
comment:
  Hi,

   I need the "tk_messageBox" with an additional flag

    >>> -timeout <<< with default value "0"

   why? 
   My application creates a couples of messageboxes and every
   MessageBox uses the same code to create. 
   => if you look into the file "msgbox.tcl" every
  MessageBox is 
      waiting for 
    >>> tkwait variable tkPriv(button) <<<
   to get the button pressed.
   this is a problem because if the application runs
  overnight the
   eval-loop is filled up with "unpressed" MessageBoxes.
   to solve this problem the flag "-timeout" was
  introduced and
   the behaviour is to press the default-button after
  "-timeout" ms

  code:

  tcl 8.3.4
  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
  152d151
  <         {-timeout "" "" "0"}
  400,402d398
  <     if {$data(-timeout)} {
  <       after $data(-timeout) set tkPriv(button)
  $data(-default)
  <     }
  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


  mfg

    aotto


tkt_uuid: 820278ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 82. X11 Emulation
priority: 5 Medium
foundin: None
resolution: Fixed
title: XFillRectangle[s] ignores XGCValues.function if non-stippled
comment:
  The XFillRectangle() and XFillRectangles() functions in 
  the Xlib emulation functions for Windows platforms do 
  not utilize the XGCValues.function data member of the 
  specified graphics context (always behaves the same as 
  GXcopy) if the XGCValues.fill_style specifies a non-
  stippled fill style.


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: 820519ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 79. L10N
priority: 9 Immediate
foundin: None
resolution: Fixed
title: New messages file for Dutch locale
comment:
  The file nl.msg, as distributed, contained a few
  erroneous entries and a number were missing. I have
  updated the messages (in cooperation with Pascal
  Scheffers) and attach this new version.


tkt_uuid: 821088ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Fix for incorrect disabled button image
comment:
  Attached are diffs to correct the incorrect stipple
  area for
  images on disabled buttons.

  This should fix bugs 818489 and 792533.

  The fix is very simple, to correct a typo using
  imageXOffset
  instead of imageYOffset.  However the code was not
  so robust because in some places it was using different
  variables to set the image position compared to the stipple
  position.  This made the bug less obvious to detect.
  So I have also changed the calls to Tk_RedrawImage to
  use the same variables (imageX/YOffset) throughout.

  The diffs are for the tk*Button.c files against the
  tk8.4.3 version.


tkt_uuid: 822002ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Duplicate
title: Clipboard is lost on exit
comment:
  This report is based on the OS/2 port, likely (and
  reportedly) to behave the same in Windows. Unix too???

  The current clipboard code is message based.  When you
  put something to clipboard, Tk claimes itself the owner
  of clipboard.  But it does not put there anything yet
  (somebody thought that this is an optimization?!). 
  When another application requests clipboard contents,
  the owner (Tk) is notified (via a message), and then it
  fills the contents. However, if nobody asks, Tk won't
  put anything when it exits.

  On exit, the owner of the clipboard gets a message
  requesting filling the clipboard.  On OS/2 this is
  WM_RENDERALL (sp?).  Tk throws this message away; it
  should not, and should process it as another message
  requesting clipboard contents.

  Jeff Hobbs writes at c.l.t.:
  "...If you actually do paste the copied data from the
  clipboard once, it will remain there after the app
  exits.  The one thing that is missing is that Tk
  doesn't force the copy onto the
  clipboard at app exit.  The reason Tk is lazy in the
  copy is to prevent large data sets being copied..."

  My personal view is there should be both a "lazy"
  method, to "prevent large data sets being copied", and
  a "force" method, to make sure the new clipboard
  content will be there after an exit. The programmer can
  always check the size of the data currently stored in
  the clipboard and choose between the "lazy" or "force"
  methods on exit.


tkt_uuid: 824479ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 2
foundin: obsolete: 8.4.4
resolution: Fixed
title: Another way to crash Tk
comment:
  Here's another way to crash Tk:

  trace variable OUCH r { kill }
  proc kill {args} { destroy .b }
  checkbutton .b
  .b configure -variable OUCH

  ==> segmentation fault

  Low priority, as this is an unlikely scenario.


tkt_uuid: 826614ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 7 High
foundin: obsolete: 8.4.4
resolution: Fixed
title: tkConfig.sh doesn't set TK_STUB_LIB_SPEC
comment:
  (This is for the ActiveState ActiveTcl 8.4.4.0 release-- 
  don't know if it's a problem with other Windows builds.)

  Anyway, the "tkConfig.sh" file in ActiveTcl 8.4.4.0 sets

  TK_STUB_LIB_SPEC=''
  TK_LIB_SPEC=''

  So TEA-based Tk extensions fail to compile properly 
  unless this file is patched.


tkt_uuid: 826850ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: Radiobuttons no visible in 8.5a0
comment:
  Testing 8.5a0 under Unix:

  The new (nice) Radiobuttons are not visible in all of
  our dialogs.

  We can't figure out why.

  But using the iwidget - Radiobox - Example leads
  to the same problem:

  !/bin/sh
  #
  ----------------------------------------------------------------------
  #  DEMO: radiobox in [incr Widgets]
  #
  ----------------------------------------------------------------------
  #\
  exec itkwish "$0" ${1+"$@"}
  package require Iwidgets 3.0

  # itkwish interprets the rest...
  #
  ----------------------------------------------------------------------
  iwidgets::radiobox .rb -labeltext "Size:" -labelpos nw
  pack .rb -padx 4 -pady 4 -fill both

  .rb add small -text "Small"
  .rb add med -text "Medium"
  .rb add large -text "Large"
  .rb add xlarge -text "Biggie"

  .rb select med


tkt_uuid: 827535ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 9 Immediate
foundin: obsolete: 8.4.4
resolution: Fixed
title: tk_dialog can prevent user interaction
comment:
  On Windows XP, the following simple script:

  tk_dialog .dial0 "test" [string repeat "hello there\n"
  500] {} ok cancel

  makes the dialog appear offscreen (at '901 -4946'). 
  Given that none of the dialog is visible to the user at
  all, the effect is a total application hang!

  The problem appears to be caused here (in dialog.tcl):

      update idletasks
      set x [expr {[winfo screenwidth $w]/2 - [winfo
  reqwidth $w]/2 \
      - [winfo vrootx [winfo parent $w]]}]
      set y [expr {[winfo screenheight $w]/2 - [winfo
  reqheight $w]/2 \
      - [winfo vrooty [winfo parent $w]]}]
      wm geom $w +$x+$y
      wm deiconify $w

  For whatever reason 'winfo reqheight $w' is returning a
  vast number like 11092 (which may well be correct
  here).  This number is then used to position the
  dialog, but then the actual height of the dialog when
  it appears is different (much smaller) and so when the
  dialog appears it is totally offscreen (and then the
  grab completes the lock-up). 

  The root of the bug appears to be elsewhere.  I suggest
  that at least for Tk 8.4.5 a test is put in dialog.tcl
  so that huge dialogs don't go offscreen.  Perhaps
  something as simple as

  if {$y < 0 && [winfo reqheight $w] > [winfo
  screenheight $w]} { set y 0 }


tkt_uuid: 828121ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Out of Date
title: TkAqua: checkbutton label overlaps the box
comment:
  The recent fixes to checkbutton label drawing (to
  prevent text wrapping) lead to a new problem where
  checkbuttons drawn with a small font have the textual
  label overlap the gui-checkbox element.

  For example:

  # In Wish console:
  frame .f -width 300 ; pack .f ; # just to make sure
  window is wide
  checkbutton .c1 -text Hello ; pack .c1
  checkbutton .c2 -text Hello -font "Times 9" ; pack .c2

  the first checkbtton is ok, but the second one has the
  'H' overlapping the
  right hand edge of the checkbox.


tkt_uuid: 829003ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Invalid
title: Tk_getOpenFile in Aqua requires that initialfile exists
comment:
  Tcl/Tk 8.4.4 Aqua for MacOS X (rel. 10.2.8) requires
  that a file specified as initial file exist.

  Example:

  set FileName [tk_getOpenFile -initialfile example.txt]

  If the file example does not exists, tk_getOpenFile aborts
  with the message

  bad initialfile "example.txt" file does not exist.

  On other platforms incl. fink the initial file name is
  listed by the widget. The Aqua widget has no room
  for this and a suitable behaviour could be just to
  ignore the initialfile name if the file does not exist.

  Furthermore, file types are ignored. Thus even

  set FileName [tk_getOpenFile -filetypes { 
  {{Text Files} {.txt}}
  }]

  is specified, all files in the directory are listed.

  Peter Balling
  pballing@asc-consult.com


tkt_uuid: 829686ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 7 High
foundin: obsolete: 8.5a0
resolution: Fixed
title: AIX 64bit configure
comment:
  configure sets SHLIB_LD_FLAGS correctly but Makefile.in 
  does not use it.

  The following patch fixes the problem:
  Index: Makefile.in
  =====================================
  ==============================
  RCS file: /cvsroot/tktoolkit/tk/unix/Makefile.in,v
  retrieving revision 1.89
  diff -u -r1.89 Makefile.in
  --- Makefile.in 31 May 2003 18:32:20 -0000      1.89
  +++ Makefile.in 24 Oct 2003 15:30:32 -0000
  @@ -236,6 +236,7 @@
   STLIB_LD               = @STLIB_LD@
   SHLIB_LD               = @SHLIB_LD@
   SHLIB_LD_LIBS          = @SHLIB_LD_LIBS@
  +SHLIB_LD_FLAGS         = @SHLIB_LD_FLAGS@
   TK_SHLIB_LD_EXTRAS     = @TK_SHLIB_LD_EXTRAS@
   
   # Additional search flags needed to find the various shared 
  libraries


tkt_uuid: 829925ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 41. Photo Images
priority: 7 High
foundin: obsolete: 8.4.4
resolution: None
title: image put errors on {} color
comment:
  image put dies when passed "" as a color, although this 
  can be used in various other places in Tk to mean 
  an "empty" color or transparent color.  image put should 
  do the same, so you can pass in large color arrays that 
  don't specifically have to set a color for all pixels.


tkt_uuid: 830664ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Release Notes
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Out of Date
title: README doc bug
comment:
  tk8.3.4 unix/README reads (line 28):
  "(a) Make sure that the Tcl 8.3 release is present in the directory ../../tcl8.3"

  This doesn't work. I have used Tcl 8.3 release tcl 8.3.4 and named the directory tcl8.3 and compilation error resulted in tk. There should probably be:

  "(a) Make sure that the Tcl 8.3.x release is present in the directory ../../tcl8.3.x"


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: 830668ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Duplicate
title: umask 027 issue
comment:
  tk 8.3.4

  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: 830674ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: None
title: umask 027 causes bad wish installation
comment:
  tk 8.3.4
   When umask 027 is set during "make" stage (doesn't have
  to be set during "make install" stage), the wish8.3
  executable has permissions rwxr-x--- which renders it
  unusable for normal user.


tkt_uuid: 831627ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: None
title: if embedded windows used, exit command causes a crash
comment:
  If I create any embedded windows in wish 8.4.4 (using 
  the toplevel's -container and -use options), issuing the 
  command "exit" will cause wish to pop the error 
  message "TkGetOtherWindow couldn't find window" and 
  then to crash.

  For example, sourcing the following script will crash wish 
  8.4.4:

      set parent [ toplevel .parent -container 1 ];
      
      set embedded [ toplevel .embedded -use [ winfo id 
  $parent ] ];
      
      exit;

  The problem seems to occur because the embedded 
  windows list is not cleared properly.  File 
  win/tkWinEmbed.c:

  ThreadSpecificData *tsdPtr =  (ThreadSpecificData *)
  Tcl_GetThreadData(&dataKey, sizeof
  (ThreadSpecificData));

  tsdPtr->firstContainerPtr

  etc.


tkt_uuid: 832691ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 76. Widget Tour
priority: 5 Medium
foundin: None
resolution: Fixed
title: Allow demos to be installed anywhere
comment:
  The demos currently base themselves off of $tk_library.
  These patches remove that dependency, and allow the
  demos to be installed in any directory.  In case of
  error getting the directory, the demos will fallback to
  using $tk_library.


tkt_uuid: 833606ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5a0
resolution: Fixed
title: TkAqua: mousewheel binding incorrect
comment:
  The text.tcl binding:

  bind Text <MouseWheel> {
      %W yview scroll [expr {- (%D / 120) * 4}] units
  }

  isn't right.  If '%D' is a smallish positive number
  (e.g. 100), then the whole expression is rounded down
  to zero and no scrolling takes place.  This is
  different to the case where %D is a smallish negative
  number, where the expression will always be rounded
  down to -1 * 4, and scrolling will take place.

  I believe we should use something like:

  if {%D < 0} {
      %W yview scroll [expr {- (%D / 120) * 4}] units
  } else {
      %W yview scroll [expr { (-%D / 120) * 4}] units
  }

  On a separate note, I believe the magnitudes of %D
  between the Windows and MacOS X implementations of this
  binding are totally different.  The documentation says
  the smallest value on Windows is 120.  On MacOS X it
  has a smallest value of 1, I believe.  This suggests
  something like this would be correct:

  if {[tk windowingsystem] eq "aqua"} {
      bind Alpha <MouseWheel> {
  %W yview scroll [expr {-%D * 4}] units
      }
  } else {
      bind Alpha <MouseWheel> {
  if {%D < 0} {
      %W yview scroll [expr {- (%D / 120) * 4}] units
  } else {
      %W yview scroll [expr { (-%D / 120) * 4}] units
  }
      }
  }


tkt_uuid: 833627ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5a0
resolution: Fixed
title: TIP 155 text widget crashes and panics.
comment:
  I ran the new TIP 155 text widget with tkchat and it
  raised a Tk panic with the message
   "LayoutDLine couldn't place any characters on a line"

  This is due to the presence of elided text in the
  widget. I am hiding the entry messages and if I have
  these to be shown then it doesn't panic.

  While trying to produce a minimal example I get a crash
  from the following tcl code. (This is Win2k Tcl and Tk
  HEAD).

    pack [text .t]
    .t insert 0.0 HELLO
    .t tag configure HIDE -elide 1
    .t tag add HIDE 0.0 end


tkt_uuid: 833761ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
foundin: obsolete: 8.5a0
resolution: Fixed
title: new test failures
comment:
  Starting with today's HEAD, these tests
  fail on Solaris 9:

  ==== textDisp-13.7 TkTextSeeCmd procedure FAILED
  ==== Contents of test case:

      .t xview moveto 0
      .t yview moveto 0
      .t tag add sel 30.20
      .t tag add sel 30.40
      update
      .t see 30.50
      set x [list [.t bbox 30.50]]
      .t see 30.39
      lappend x [.t bbox 30.39]
      .t see 30.38
      lappend x [.t bbox 30.38]
      .t see 30.20
      lappend x [.t bbox 30.20]

  ---- Result was:
  {73 64 7 13} {3 64 7 13} {3 64 7 13} {73 64 7 13}
  ---- Result should have been (exact matching):
  {73 55 7 13} {3 55 7 13} {3 55 7 13} {73 55 7 13}
  ==== textDisp-13.7 FAILED


  ==== textDisp-13.8 TkTextSeeCmd procedure FAILED
  ==== Contents of test case:

      .t xview moveto 0
      .t yview moveto 0
      .t tag add sel 30.20
      .t tag add sel 30.50
      update
      .t see 30.50
      set x [list [.t bbox 30.50]]
      .t see 30.60
      lappend x [.t bbox 30.60]
      .t see 30.65
      lappend x [.t bbox 30.65]
      .t see 30.90
      lappend x [.t bbox 30.90]

  ---- Result was:
  {73 64 7 13} {136 64 7 13} {136 64 7 13} {73 64 7 13}
  ---- Result should have been (exact matching):
  {73 55 7 13} {136 55 7 13} {136 55 7 13} {73 55 7 13}
  ==== textDisp-13.8 FAILED

  ==== textDisp-13.9 TkTextSeeCmd procedure FAILED
  ==== Contents of test case:

      wm geom . [expr $width-2]x$height
      .t xview moveto 0
      .t yview moveto 0
      .t tag add sel 30.20
      .t tag add sel 30.50
      update
      .t see 30.50
      set x [list [.t bbox 30.50]]
      .t see 30.60
      lappend x [.t bbox 30.60]
      .t see 30.65
      lappend x [.t bbox 30.65]
      .t see 30.90
      lappend x [.t bbox 30.90]

  ---- Result was:
  {80 66 7 13} {136 66 7 13} {136 66 7 13} {80 66 7 13}
  ---- Result should have been (exact matching):
  {80 55 7 13} {136 55 7 13} {136 55 7 13} {80 55 7 13}
  ==== textDisp-13.9 FAILED


  ==== textDisp-16.16 TkTextYviewCmd procedure, "moveto"
  option FAILED
  ==== Contents of test case:

      .t yview moveto .754
      .t index @0,0

  ---- Result was:
  151.60
  ---- Result should have been (exact matching):
  151.80
  ==== textDisp-16.16 FAILED
  ==== textDisp-16.18 TkTextYviewCmd procedure, "moveto"
  roundoff FAILED
  ==== Contents of test case:

      catch {destroy .top1}
      toplevel .top1
      wm geometry .top1 +0+0
      text .top1.t -height 3 -width 4 -wrap none -setgrid
  1 -padx 6  -spacing3 6
      .top1.t insert end "1\n2\n3\n4\n5\n6"
      pack .top1.t
      update
      .top1.t yview moveto 0.3333
      set result [.top1.t yview]
      destroy .top1
      set result

  ---- Result was:
  0.333333333333 0.833333333333
  ---- Result should have been (exact matching):
  0.333333 0.833333
  ==== textDisp-16.18 FAILED


  ==== textDisp-16.28 TkTextYviewCmd procedure, "scroll"
  option, forward pages FAILED
  ==== Contents of test case:

      .t yview 98.0
      update
      .t yview scroll 1 page
      .t index @0,0

  ---- Result was:
  102.0
  ---- Result should have been (exact matching):
  103.0
  ==== textDisp-16.28 FAILED

  ==== textDisp-17.7 TkTextScanCmd procedure FAILED
  ==== Contents of test case:

      .t yview 10.0
      .t xview moveto 0
      .t xview scroll 20 units
      .t scan mark -10 60
      .t scan dragto -5 65
      .t index @0,0
      set x [.t index @0,0]
      .t scan dragto 0 70
      list $x [.t index @0,0]

  ---- Result was:
  6.13 2.6
  ---- Result should have been (exact matching):
  7.13 3.6
  ==== textDisp-17.7 FAILED


  ==== textDisp-17.10 TkTextScanCmd procedure, word
  wrapping FAILED
  ==== Contents of test case:

      .t yview 10.0
      .t scan mark -10 60
      .t scan dragto -5 65
      set x [.t index @0,0]
      .t scan dragto 0 70
      list $x [.t index @0,0]

  ---- Result was:
  9.15 8.31
  ---- Result should have been (exact matching):
  9.31 8.47
  ==== textDisp-17.10 FAILED

  ==== textDisp-19.12 GetYView procedure, partially
  visible last line FAILED
  ==== Contents of test case:

      catch {destroy .top}
      toplevel .top
      wm geometry .top +0+0
      text .top.t -width 40 -height 5
      pack .top.t -expand yes -fill both
      .top.t insert end "Line 1\nLine 2\nLine 3\nLine
  4\nLine 5"
      # Need to wait for asychronous calculations to
  complete.
      update ; after 10
      scan [wm geom .top] %dx%d twidth theight
      wm geom .top ${twidth}x[expr $theight - 3]
      update
      .top.t yview

  ---- Result was:
  0.0 0.96
  ---- Result should have been (exact matching):
  0.0 0.9625
  ==== textDisp-19.12 FAILED


  ==== textDisp-19.13 GetYView procedure, partially
  visible last line FAILED
  ==== Contents of test case:

      catch {destroy .top}
      toplevel .top
      wm geometry .top +0+0
      text .top.t -width 40 -height 5
      pack .top.t -expand yes -fill both
      .top.t insert end "Line 1\nLine 2\nLine 3\nLine 4
  has enough text to wrap around at least once"
      update
      scan [wm geom .top] %dx%d twidth theight
      wm geom .top ${twidth}x[expr $theight - 3]
      update
      .top.t yview

  ---- Result was:
  0.0 0.96
  ---- Result should have been (exact matching):
  0 0.942308
  ==== textDisp-19.13 FAILED



  ==== textDisp-19.16 count -ypixels FAILED
  ==== Contents of test case:

      .t configure -wrap word
      .t delete 1.0 end
      .t insert 1.0 "Line 1"
      foreach i {2 3 4 5 6 7 8 9 10 11 12 13 14 15} {
          .t insert end "\nLine $i"
      }
      .t insert end "\nThis last line wraps around four "
      .t insert end "times with a bit left on the last line."
      # Need to update so everything is calculated.
      update
      set res {}
      lappend res  [.t count -ypixels 1.0 end]  [.t count
  -update -ypixels 1.0 end]  [.t count -ypixels 15.0
  16.0]  [.t count -ypixels 15.0 "16.0 displaylineend
  +1c"]  [.t count -ypixels 16.0 "16.0 displaylineend
  +1c"]  [.t count -ypixels "16.0 +1 displaylines" "16.0
  +4 displaylines +3c"]

  ---- Result was:
  260 260 13 26 13 39
  ---- Result should have been (exact matching):
  300 300 15 30 15 45
  ==== textDisp-19.16 FAILED


  ==== textDisp-20.2 FindDLine FAILED
  ==== Contents of test case:

      .t yview 100.0
      .t yview -pickplace 53.0
      list [.t dlineinfo 50.0] [.t dlineinfo 50.14] [.t
  dlineinfo 50.15]

  ---- Result was:
  {3 -1 105 13 10} {3 -1 105 13 10} {3 12 140 13 10}
  ---- Result should have been (exact matching):
  {} {} {3 3 140 13 10}
  ==== textDisp-20.2 FAILED



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

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

  ---- Result was:
  {0.0 0.466666666667} 300x50+5+18 {12 68 7 13}
  ---- Result should have been (exact matching):
  {0 0.466667} 300x50+5+18 {12 68 7 13}
  ==== textDisp-29.1 FAILED


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

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

  ---- Result was:
  {0.0233333333333 0.49} 300x50+-2+18 {5 68 7 13}
  ---- Result should have been (exact matching):
  {0.0233333 0.49} 300x50+-2+18 {5 68 7 13}
  ==== textDisp-29.2 FAILED



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

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

  ---- Result was:
  {0.536666666667 1.0} 300x50+-156+18 {}
  ---- Result should have been (exact matching):
  {0.536667 1} 300x50+-156+18 {}
  ==== textDisp-29.3 FAILED


  ==== textDisp-31.1 line embedded window height update
  FAILED
  ==== Contents of test case:

      set res {}
      .t delete 1.0 end
      .t insert end "abcd\nefgh\nijkl\nmnop\nqrst\nuvwx\nyx"
      frame .t.f -background red -width 100 -height 100
      .t window create 3.0 -window .t.f
      lappend res [.t count -update -ypixels 1.0 end]
      .t.f configure -height 10
      lappend res [.t count -ypixels 1.0 end]
      lappend res [.t count -update -ypixels 1.0 end]
      set res

  ---- Result was:
  178 178 91
  ---- Result should have been (exact matching):
  190 190 105
  ==== textDisp-31.1 FAILED



  ==== textDisp-31.2 line update index shifting FAILED
  ==== Contents of test case:

      set res {}
      .t.f configure -height 100
      update
      lappend res [.t count -update -ypixels 1.0 end]
      .t.f configure -height 10
      .t insert 1.0 "abc\n"
      .t insert 1.0 "abc\n"
      lappend res [.t count -ypixels 1.0 end]
      lappend res [.t count -update -ypixels 1.0 end]
      .t.f configure -height 100
      .t delete 1.0 3.0
      lappend res [.t count -ypixels 1.0 end]
      lappend res [.t count -update -ypixels 1.0 end]
      set res

  ---- Result was:
  178 204 117 91 178
  ---- Result should have been (exact matching):
  190 220 135 105 190
  ==== textDisp-31.2 FAILED

  ==== textDisp-31.3 line update index shifting FAILED
  ==== Contents of test case:

      # Should do exactly the same as the above, as long
      # as we are correctly tagging the correct lines for
      # recalculation.  The 'update' and 'delay' must be
      # long enough to ensure all asynchronous updates
      # have been performed.
      set res {}
      .t.f configure -height 100
      update
      lappend res [.t count -update -ypixels 1.0 end]
      .t.f configure -height 10
      .t insert 1.0 "abc\n"
      .t insert 1.0 "abc\n"
      lappend res [.t count -ypixels 1.0 end]
      update ; after 1000 ; update
      lappend res [.t count -ypixels 1.0 end]
      .t.f configure -height 100
      .t delete 1.0 3.0
      lappend res [.t count -ypixels 1.0 end]
      update ; after 1000 ; update
      lappend res [.t count -ypixels 1.0 end]
      set res

  ---- Result was:
  178 204 117 91 178
  ---- Result should have been (exact matching):
  190 220 135 105 190
  ==== textDisp-31.3 FAILED


  ==== textDisp-31.4 line embedded image height update FAILED
  ==== Contents of test case:

      set res {}
      image create photo textest -height 100 -width 10
      .t delete 3.0
      .t image create 3.0 -image textest
      update
      lappend res [.t count -update -ypixels 1.0 end]
      textest configure -height 10
      lappend res [.t count -ypixels 1.0 end]
      lappend res [.t count -update -ypixels 1.0 end]
      set res

  ---- Result was:
  178 178 91
  ---- Result should have been (exact matching):
  190 190 105
  ==== textDisp-31.4 FAILED

  ==== textDisp-31.5 line update index shifting FAILED
  ==== Contents of test case:

      set res {}
      textest configure -height 100
      update ; after 1000 ; update
      lappend res [.t count -update -ypixels 1.0 end]
      textest configure -height 10
      .t insert 1.0 "abc\n"
      .t insert 1.0 "abc\n"
      lappend res [.t count -ypixels 1.0 end]
      lappend res [.t count -update -ypixels 1.0 end]
      textest configure -height 100
      .t delete 1.0 3.0
      lappend res [.t count -ypixels 1.0 end]
      lappend res [.t count -update -ypixels 1.0 end]
      set res

  ---- Result was:
  178 204 117 91 178
  ---- Result should have been (exact matching):
  190 220 135 105 190
  ==== textDisp-31.5 FAILED

  ==== textDisp-31.6 line update index shifting FAILED
  ==== Contents of test case:

      # Should do exactly the same as the above, as long
      # as we are correctly tagging the correct lines for
      # recalculation.  The 'update' and 'delay' must be
      # long enough to ensure all asynchronous updates
      # have been performed.
      set res {}
      textest configure -height 100
      update ; after 1000 ; update
      lappend res [.t count -update -ypixels 1.0 end]
      textest configure -height 10
      .t insert 1.0 "abc\n"
      .t insert 1.0 "abc\n"
      lappend res [.t count -ypixels 1.0 end]
      update ; after 1000 ; update
      lappend res [.t count -ypixels 1.0 end]
      textest configure -height 100
      .t delete 1.0 3.0
      lappend res [.t count -ypixels 1.0 end]
      update ; after 1000 ; update
      lappend res [.t count -ypixels 1.0 end]
      set res

  ---- Result was:
  178 204 117 91 178
  ---- Result should have been (exact matching):
  190 220 135 105 190
  ==== textDisp-31.6 FAILED

  ==== textWind-10.4 EmbWinLayoutProc procedure, error in
  creating window FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      .t window create 1.5 -create {
          frame .t.f
          frame .t.f.f -width 10 -height 20 -bg $color
      }
      set msg xyzzy
      update
      list $msg [.t bbox 1.5] [winfo exists .t.f.f]

  ---- Result was:
  {{window name "f" already exists in parent}} {40 11 0 0} 1
  ---- Result should have been (exact matching):
  {{can't embed .t.f.f relative to .t}} {40 11 0 0} 1
  ==== textWind-10.4 FAILED


  ==== textWind-10.6 EmbWinLayoutProc procedure, error in
  creating window FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      .t window create 1.5 -create {
          toplevel .t2 -width 100 -height 150
          wm geom .t2 +0+0
          concat .t2
      }
      set msg xyzzy
      update
      list $msg [.t bbox 1.5]

  ---- Result was:
  {{window name "t2" already exists in parent}} {40 11 0 0}
  ---- Result should have been (exact matching):
  {{can't embed .t2 relative to .t}} {40 11 0 0}
  ==== textWind-10.6 FAILED


tkt_uuid: 833819ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: Fixed
title: large directory support
comment:
  tk_get*File has difficulties with a directory of 25000
  elements.

  Using [file isdir ./$f] is a factor of 10 slower than
  [file isdir $f] for Tcl 8.4.2 on IRIX64 6.5, as the
  following example shows:

  (bfd) 68 % time { foreach f [glob *] { file isdir $f } } 5
  317112 microseconds per iteration
  (bfd) 69 % time { foreach f [glob *] { file isdir ./$f
  } } 5
  3496268 microseconds per iteration
  (bfd) 97 % llength [glob *]
  2113

  The problem is less severe (only a factor of 3) on
  Debian Linux 2.4.20-xfs:

  (bfd) 53 % time { foreach f [glob *] { file isdir $f } } 5
  220577 microseconds per iteration
  (bfd) 54 % time { foreach f [glob *] { file isdir ./$f
  } } 5
  597074 microseconds per iteration
  (bfd) 56 % llength [glob *]
  2000

  The attached patch replace ./$f with $f, and only calls
  isdir once rather than twice.

  The call to IconList_Add with the resulting file list
  is also slow, but this patch does not address that issue.

  ::tk::IconList_Add $data(icons) $file $matchList


tkt_uuid: 835010ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: Unused variable warning in tkTextDisp.c
comment:
  Compiling with GCC 2.96 on Linux/*x86

  /home/fellowsd/lang/tcl/cvs/maintenance/8.5/tk/unix/../generic/tkTextDisp.c:In
  function `DlineXOfIndex':
  /home/fellowsd/lang/tcl/cvs/maintenance/8.5/tk/unix/../generic/tkTextDisp.c:5736:warning:
  unused variable `dInfoPtr'


tkt_uuid: 835173ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: TkAqua: tk_getSaveFile disallows '.' filenames
comment:
  'tk_getSaveFile' keeps the save button dimmed if you
  try to enter any name, like '.cshrc' which starts with
  a '.'.


tkt_uuid: 835832ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: None
resolution: None
title: tearoff menu add's should return index
comment:
  When I have code like this, I would like to be able to
  store the index number of particular options for later use.

      menu .mbar
      . config -menu .mbar

      .mbar add cascade -label "File" -underline 0 \
  -menu [menu .mbar.file -tearoff 0]
      .mbar add cascade -label "Help" -underline 0 \
  -menu [menu .mbar.help -tearoff 0]

      set m .mbar.file
      $m add command -label "Open Test Suite" -underline 0 \
  -command gui::opentestsuite

  This simple patch does what I need.  There is probably
  extra work/thinking to do to make sure that everything
  is consistent...


tkt_uuid: 835997ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: None
title: generate event ignored if wdg never displayed (OSX)
comment:
  If a widget has never been displayed then it cannot 
  generate an event; any attempt is silently ignored.

  To see the bug:
  - Run the sample script below
  - Push the button "Send Foo". This tells the label .l to 
  generate a <<Foo>> event
  - "got foo" is NOT printed, indicating that the <<Foo>> 
  event was not generated
  - Toggle the checkbutton "Show Label" one or more 
  times, to display the label and possibly hide it again
  - Push the button. The event is generated.

  Summary: pushing the button "Send Foo" has no effect 
  (i.e. the <<Foo>> event is not generated) until the label "I 
  Send Foo" has been displayed at least once. After that the 
  event is generated reliably. I first discovered this problem 
  with a far more complex widget than a label.

  I observed this bug in Tcl/Tk 8.4.4 on MacOS X.

  --------- sample script follows ----------

  label .l -text "I generate Foo"
  grid .l -row 2 -column 0
  grid remove .l
  variable x

  checkbutton .c -text "Show Label" -variable x -command {
  if {$x} {
  grid .l
  } else {
  grid remove .l
  }
  }
  grid .c -row 1 -column 0

  button .b -text "Send Foo" -command {
  event generate .l "<<Foo>>"
  }
  grid .b -row 0 -column 0

  bind . "<<Foo>>" {
  puts "got foo"
  }


tkt_uuid: 836483ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 8
foundin: obsolete: 8.4.4
resolution: Fixed
title: listbox itemconfigure causes a memory leak
comment:
  The following tcl program causes a memory leak. The 
  leak is because of the ".lst itemconfigure" lines:


  proc start {} {
      listbox .lst -background White -yscrollcommand 
  {.scrly set} -xscrollcommand {.scrlx set}
      scrollbar .scrly -command {.lst yview}
      scrollbar .scrlx -command {.lst xview} -orient 
  horizontal
      grid columnconf . 0 -weight 1
      grid rowconf . 0 -weight 1
      grid .lst -in . -column 0 -row 0 -sticky swne
      grid .scrly -in . -column 1 -row 0 -sticky ns
      grid .scrlx -in . -column 0 -row 1 -sticky ew
      bind .lst <<ListboxSelect>> {.lst selection clear 0 
  end}

      for {set x 0} {$x<10000000} {incr x} {
          for {set y 0} {$y<100} {incr y} {
              .lst insert end  "$x: iteration $y"
              .lst itemconfigure $y -foreground #888888
              .lst itemconfigure $y -selectbackground #4444ff
              update
          }
          .lst delete 0 end
      }
  }

  start


tkt_uuid: 837300ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5a0
resolution: Fixed
title: Infinite sequences of events in tkTextDisp.c
comment:
  The test file textDisp.test hangs in a state where it
  is still handling events while executing textDisp-9.2
  on Linux/*x86 with display sent to an SGI O2 running
  IRIX6.5 over SSH.  This is *bad* since it impacts upon
  the whole test suite's running to completion!


tkt_uuid: 837870ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Bezier canvas support
comment:
  This provides support for bezier curves as a canvas type.  
  The support was added for the BRL-CAD package and has 
  existed and been distributed for several years; the original 
  author is John Anderson of the U.S. Army Research 
  Laboratory.

  There may be some "polish" still required to make the 
  canvas type behave like all of the rest, but the functionality 
  is there and useable as is.  We've found it useful, I imagine 
  others will too.

  The patch is rather simple.  There is a new file, 
  tkCanvBezier.c that goes in generic/. as well as the 
  necessary entries in unix/Makefile.in provided as a diff -u 
  patch.

  Cheers!
  Sean


tkt_uuid: 840978ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: MacOSX scrollbar limits are off: 0.0 0.9 is about 50%
comment:
  This is on TkAqua:

  toplevel .t
  scrollbar .t.s
  pack .t.s -side left  -fill y

  followed by '.t.s set 0.0 0.5' one would assume to see the 
  scrollbar with the 'bar' occupying the first 50% of the trough. 
  Instead it's about 30%.

  .t.s set 0.0 0.999 ;# occupies about 50%

  I should also point out there's another problem with dragging the 
  scrollbar -- the mouse sort of slips along it, with the scrollbar 
  dragging more slowly than the mouse moves, and you have to 
  drag all the way beyond the double arrow at one end to actually 
  move the whole scrollbar to one extreme. The way the scrollbar 
  should work is that each pixel the mouse moves equates to the 
  same movement of the scrollbar-slider.


tkt_uuid: 841244ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: update to coregraphics (OSX)
comment:
  this is a diff against 11/12/2003 cvs

  basically it just makes some changes to tkMacOSXDraw.c

  by switching the variable "useCGDrawing" at the top of the 
  file, you can switch back and forth between quickdraw and 
  coregraphics...

  unfortunately, it doesn't cover pixmaps (yet)

  ...or get rid of copybits (yet)

  ...but, it does help out with a bit with primitive drawings 
  (rectangles, lines, arcs, polygons)

  tested with 10.2.6-10.2.8

  ...known bugs:  

  - stipples don't work
  - antialiasing:  when should it kick in?
  - others?


tkt_uuid: 841280ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: None
resolution: None
title: spinbox -from and -to defaults/behaviour
comment:
  Not sure if this qualifies as a bug ...

  I want to configure the allowed range for a spinbox from 
  10 to 20:

     % info tclversion
     8.4
     (bin) 2 % spinbox .s
     .s
     (bin) 3 % .s configure -from 10
     -to value must be greater than -from value

  As the defaults for Tk's spinbox -from and -to are both 
  zero, it follows that I'm forced to first change the -to 
  value followed by the -from one, or change both at 
  once. My impression is that the defaults should be from 
  MININT to MAXINT or some such. Notice that the 
  defaults for Tk's scale -from and -to are 0.0 and 100.0, 
  respectively.

  Other solution suggested in comp.lang.tcl was the 
  following: rather than bailing out, autoadjust 
  the "other" end to be equal to the one currently set. 
  (except if both are set in one go)


tkt_uuid: 842498ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: text widget xview confused when window just being created
comment:
  The following simple test shows the bug:

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

  (make sure you evaluate it all in one go, NOT
  interactively, since we don't want events to trigger in
  between each command)

  The problem is the attempt to scroll by 5 units (i.e.
  characters) fails, and the window only scrolls by 1 unit.

  The reason?  Here's what I've debugged, but I'm not in
  need of advice:

  The problem is ultimately caused by this line in
  UpdateDisplayInfo (which is called by DisplayText):

      if (dInfoPtr->newByteOffset > maxOffset) {
  dInfoPtr->newByteOffset = maxOffset;
      }

  But the problem is that at this point 'maxOffset' is
  much too small, and so the newByteOffset (which was
  correct at 5 units) is thrown away and reduced to 1.

  So, why is maxOffset too small?  That's because while
  UpdateDisplayInfo iterates over the DLines in the
  widget, after laying out the first line (with maxOffset
  = 1 char), it finds that the current y position is
  greater than dInfoPtr->maxY -- i.e. greater than the
  vertical height of the widget.

  This is of course nonsense since the widget is set up
  to be some 10 characters high.  However, Tk's geometry
  calculations have not yet kicked in at this point, and
  so the text widget is still set at 1 pixel of height.

  When the geometry of the widget is eventually correctly
  set (which of course it is), it is too late for the '5
  unit' scroll, since that information has already been
  discarded as too big.

  Note that this bug has nothing to do with my Tk 8.5's
  text widget changes (both Tk 8.4 and 8.5 show the bug).

  So, is there a way that the text widget can realise
  that it hasn't yet been configured at all (but is going
  to be) and thereby DisplayText can take appropriate
  action (at the least not throw away the 5 units)?

  Could 'TK_NEED_CONFIG_NOTIFY' be used (I notice the
  TkWindow has that flag set)?  Or are there some other
  window attribute/flag that could be used?

  I notice that reqHeight is correct at the time
  UpdateDisplayInfo is called, but using instead of maxY
  is no good, since it is usually not same as the actual
  eventual height, and so we'd end up calculating too
  much or too little.


tkt_uuid: 842504ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 48. Geometry Management
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: None
title: embedded windows (in text/canvas) are not cropped
comment:
  For the canvas:

  canvas .c -width 100 -height 100 -bd 10 -relief raised
  pack .c -fill both
  frame .c.f -bg red -width 200 -height 200
  .c create window {20 20} -window .c.f

  Similarly for the text widget. For both one can also
  look closely at the widget demos.

  It appears as if Tk_MaintainGeometry and friends are
  not paying any attention to widget borders.


tkt_uuid: 842945ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 48. Geometry Management
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: None
title: out-of-process embedding support doesn't work (win32)
comment:
  After some research to find out how, thanks to the 
  tclplugin, these special windows messages need to be 
  handled by a window that will act as a container:

  // ---------  Begin Tk container specials ----------

  #define TK_CLAIMFOCUS     (WM_USER)
  #define TK_GEOMETRYREQ    (WM_USER+1)
  #define TK_ATTACHWINDOW   (WM_USER+2)
  #define TK_DETACHWINDOW   (WM_USER+3)

  case TK_CLAIMFOCUS:
      if (wParam || (GetFocus() != NULL)) {
  ::SetFocus(pBlank->hAttach);
      }
      return 0;

  case TK_GEOMETRYREQ:
      ::SetWindowPos(hwnd, NULL, 0, 0, wParam, 
  lParam,
      SWP_NOMOVE | SWP_NOZORDER 
  | SWP_NOACTIVATE);
      return 0;

  case TK_ATTACHWINDOW:
      pBlank->hAttach = (HWND)wParam;
      ::SetParent(pBlank->hAttach, hwnd);
      return 0;

  case TK_DETACHWINDOW:
      pBlank->hAttach = NULL;
      ::PostMessage(hwnd, WM_CLOSE, 0, 0);
      return 0;

  // ---------  End Tk container specials ----------

  And this is working fine for me with:

  package require Tk
  toplevel .mdi -use [IRC::makeblank]
  text .mdi.t
  pack .mdi.t

  Yet, I can't resize the window.  For each size change 
  change sent, an equal TK_GEOMETRYREQ sent back to 
  return it to where it was.  There is no message interface 
  for me to tell it to resize.

  case WM_SIZE:
      if (wParam != SIZE_MINIMIZED && pBlank-
  >hAttach) {

  goes bang->//::SendMessage(pBlank->hAttach, 
  TK_GEOMETRYREQ,
  //LOWORD(lParam),HIWORD
  (lParam));

  forced back->//::SetWindowPos(pBlank->hAttach, 
  NULL, 0, 0,
  //LOWORD(lParam), HIWORD
  (lParam),
  //SWP_NOMOVE | 
  SWP_NOZORDER | SWP_NOACTIVATE);

  NO!!!->//Tk_GeometryRequest
  (Tk_HWNDToWindow(pBlank->hAttach),
  //LOWORD(lParam), HIWORD
  (lParam));
      }
      // must fall to DefMDIChildProc(), or bad 
  things happen.
      //
      break;

  I can't call any Tk functions or my app becomes 
  dependant on it.  I am in the same process and could 
  call Tk functions, but if this window was out-of-process, 
  this would not work and is useless.

  The ability to send a message to the attached window 
  to tell the geometry manager to resize is required.


tkt_uuid: 842952ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: scrollbar dragging jumps and is too slow
comment:
  When dragging the TkAqua scrollbar, the new scrollbar
  position is calculated based upon the mouse's absolute
  position within the scrollbar-control.

  This is not how scrollbars should work, however.  The
  position should be calculated as if the user were
  actually dragging the bar physically with the mouse --
  i.e. a pixel offset should be calculated of the current
  mouse position relative to the original mouse-click
  position, and that pixel offset should then be
  reflected onto the scrollbar's coordinate system and
  applied directly.  Then a range-check should be made to
  ensure the value remains within [0,1.0]

  Furthermore, the moment the mouse strays a pixel
  outside the scrollbar control, the scrollbar position
  is reset!!  This is totally against the HIG. In fact
  the way Aqua works is to allow the mouse to be anywhere
  on screen at all, and still maniplate the scrollbar as
  long as the button is still held down (WinXP is
  slightly different and provides about an inch of leeway
  around the control).

  The first of these problems is quite clear, here:

                  if (scrollPtr->vertical == true) {
                      newFirstFraction =  (1.0 -
  thumbWidth) *
                          ((double) (currentPoint.v -
  trackBarPin) / trackBarSize);
                  } else {
                      newFirstFraction =  (1.0 -
  thumbWidth) *
                          ((double) (currentPoint.h -
  trackBarPin) / trackBarSize);
                  }

  But I'm not really knowledgeable enough to fix it.


tkt_uuid: 843172ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Wont Fix
title: win scrollbar odd behaviour.
comment:
  Not 100% sure this is a bug, but definitely odd:

  interp create foo

  interp alias foo bar {} bar
  proc bar {args} { interp delete foo ; error blah }

  foo eval {package require Tk}
  foo eval {scrollbar .s ; pack .s -side left}
  foo eval {.s configure -command bar }

  Now try to manipulate the scrollbar... I get not one
  error (which of course I would expect), but lots and
  lots of them.  In fact the 'interp delete foo' doesn't
  manage to delete the interpreter until after the mouse
  has been released.

  blah
      while executing
  "error blah "
      (procedure "bar" line 1)
      invoked from within
  "bar moveto 0"
      (scrollbar command)

  attempt to call eval in deleted interpreter
      while executing
  "bar moveto 0.0909"
      (scrollbar command)

  attempt to call eval in deleted interpreter
      while executing
  "bar moveto 0.1818"
      (scrollbar command)

  attempt to call eval in deleted interpreter
      while executing
  ...etc

  Note: if the above is carried out in the main
  interpreter, with '.s configure -command {destroy . ;
  error foo}', it's mostly ok, except that the scrollbar
  gets drawn, briefly, in the top-left corner of the
  screen (I suppose because '.' disappears, but the
  scrollbar remains and doesn't know where to draw
  itself, and doesn't know it should be dead).


tkt_uuid: 843395ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: None
resolution: Fixed
title: Wrong menu placement
comment:
  In the latest cvs head, it seems that a problem
  with menus has been introduced.
  Menus posted when you click entries in
  menubars, appear in wrong positions in the
  vertical direction.

  More specifically, the vertical placement is wrong:
  the first menu in the menubar is posted at (0,0),
  the second menu is posted fine,
  and for the rest entries menus are posted
  a lot under the menubar, with the distance increasing
  as you travel the menubar to the right.

  I have observed this under linux (redhat 9, KDE)
  and I don't know if it is observed under other
  operating systems. Tcl/Tk 8.5, latest cvs head.


tkt_uuid: 843752ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: two new test failures
comment:
  In the latest HEAD, these failures
  are new (on Linux/Alpha):

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

      .t delete 1.0 end
      .t configure -tabs {1c 2c center 3c 4c} -wrap none
  -width 40
      .t insert 1.0
  a\tb\tc\td\te\n012345678934567890a\tbb\tcc\tdd
      update
      .t bbox 2.24

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


  ==== textDisp-29.2.5 miscellaneous: can show last
  character FAILED
  ==== Contents of test case:

      catch {destroy .t2}
      toplevel .t2
      wm geometry .t2 121x141+200+200
      text .t2.t -width 5 -height 5 -font {Arial 10} 
  -wrap none -xscrollcommand "
  .t2.s set"  -bd 2 -highlightthickness 0 -padx 1
      .t2.t insert end "WWWWWWWWWWWWi"
      scrollbar .t2.s -orient horizontal -command ".t2.t
  xview"
      grid .t2.t -row 0 -column 0 -sticky nsew
      grid .t2.s -row 1 -column 0 -sticky ew
      grid columnconfigure .t2 0 -weight 1
      grid rowconfigure .t2 0 -weight 1
      grid rowconfigure .t2 1 -weight 0
      update ; update
      set xv [.t2.t xview]
      set xd [expr {[lindex $xv 1] - [lindex $xv 0]}]
      .t2.t xview moveto [expr {1.0-$xd}]
      set iWidth [lindex [.t2.t bbox end-2c] 2]
      .t2.t xview scroll 2 units
      set iWidth2 [lindex [.t2.t bbox end-2c] 2]

      if {($iWidth == $iWidth2) && $iWidth > 2} {
          set result "correct"
      } else {
          set result "not correct"
      }

  ---- Result was:
  not correct
  ---- Result should have been (exact matching):
  correct
  ==== textDisp-29.2.5 FAILED


  Also, tests textDisp-33.* take a long time to
  complete, as if they're waiting for some
  timeout to expire?


tkt_uuid: 845189ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: Fixed
title: The first call to tk_get*File modifies the following calls
comment:
  On tk-8.4.4 installed on Linux RedHat 7.2 kernel
  2.4.20, the first time you call tk_get*File -filetypes
  "typelist", the program sets the global variable
  data(extUsed) to indicate if -defaultextension option
  has been used with a non-empty value (see file
  tkfbox.tcl of the standard tk release 8.4.4 line1356
  and its 2 following blocks).  No subsequent calls of
  tk_get*File -filetypes "typelist" will change the
  original value of data(extUsed) and the decision to use
  the -defaultextension option will always depend on the
  first call to tk_get*File -filetypes "typelist".

  For example, test.tcl:

  ***************************************
  proc save_as {} {
    set typelist {
      {{Text} {.txt}}
      {{All} {*}}
    }
    set file [tk_getSaveFile -defaultextension .exe
  -filetypes $typelist]
    puts $file
  }

  pack [button .save -text "Save as" -command save_as]
  pack [button .quit -text Quit -command exit]
  set file [tk_getOpenFile -filetypes {"All *"}]
  puts $file

  **************************************
  "wish test.tcl" will add the extension .txt instead of
  .exe when the user press the "Save as" button and type
  a file without extension.  This is due to the fact that
  the call to tk_getOpenFile did not use the
  -defaultextension option and the program will always
  consider that this option is not used when tk_get*File
  is called after.  Commenting out the last two lines of
  the program will let the program behaves as it should.

  My suggestion is to delete the lines 1356 and 1362 ("if
  {![info exists data(extUsed)]} {" and "}") of the file
  tkfbox.tcl to reset data(extUsed) EVERYTIME tk_get*File
  is called according to the value of the current
  -defaultextension option value.

  Michel Pitermann


tkt_uuid: 845772ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Invalid
title: Infinite recursion on [cd]
comment:
  Under Windows 2000, with tclsh8.5 snapshot 20031119:
    cd g:
    cd c:
  crash with an infinite recursion.

  Here is the stack:

  Tcl_FSGetPathType(Tcl_Obj * 0x00912458) line 242 + 
  13 bytes

  Tcl_FSGetNormalizedPath(Tcl_Interp * 0x00000000, 
  Tcl_Obj * 0x00912458) line 1219 + 9 bytes
  TclFSEnsureEpochOk(Tcl_Obj * 0x00912458, 
  Tcl_Filesystem * * 0x0003321c) line 1444 + 11 bytes
  Tcl_FSGetFileSystemForPath(Tcl_Obj * 0x00912458) line 
  3718 + 13 bytes
  Tcl_FSGetCwd(Tcl_Interp * 0x00000000) line 2349 + 12 
  bytes

  Tcl_FSGetNormalizedPath(Tcl_Interp * 0x00000000, 
  Tcl_Obj * 0x00912458) line 1244 + 9 bytes
  TclFSEnsureEpochOk(Tcl_Obj * 0x00912458, 
  Tcl_Filesystem * * 0x000332f0) line 1444 + 11 bytes
  Tcl_FSGetFileSystemForPath(Tcl_Obj * 0x00912458) line 
  3718 + 13 bytes
  Tcl_FSGetCwd(Tcl_Interp * 0x00000000) line 2349 + 12 
  bytes

  Tcl_FSGetNormalizedPath(Tcl_Interp * 0x00000000, 
  Tcl_Obj * 0x00912458) line 1244 + 9 bytes
  TclFSEnsureEpochOk(Tcl_Obj * 0x00912458, 
  Tcl_Filesystem * * 0x000333c4) line 1444 + 11 bytes
  Tcl_FSGetFileSystemForPath(Tcl_Obj * 0x00912458) line 
  3718 + 13 bytes
  Tcl_FSGetCwd(Tcl_Interp * 0x00000000) line 2349 + 12 
  bytes

  ...


tkt_uuid: 846141ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 58. [send]
priority: 5 Medium
foundin: None
resolution: None
title: winSend.test failures and tkWinSend.c bug
comment:
  The listed tests fail on WinXP, Tk 8.5a0.  Also I note
  that code like this:

  Tcl_SetStringObj(Tcl_GetObjResult(interp),
      "option not implemented: \"displayof\" is not
  available "
      "for this platform.", -1);

  Is no good if the result object is shared -- it will
  trigger a panic.

  Vince.

  ----

  winSend.test

  ==== winSend-2.1 Tk_SendObjCmd - # of args FAILED
  ==== Contents of test case:

      list [catch {send tktest} msg] $msg

  ---- Result was:
  1 {bad option "tktest": must be -async, -displayof, or
  --wrong # args: should be
   "send ?-async? ?-displayof? ?--? interpName arg ?arg
  ...?"}
  ---- Result should have been (exact matching):
  1 {wrong # args: should be "send ?options? interpName
  arg ?arg ...?"}
  ==== winSend-2.1 FAILED


  ==== winSend-2.1 Tk_SendObjCmd: arguments FAILED
  ==== Contents of test case:

      list [catch {send -bogus tktest} msg] $msg

  ---- Result was:
  1 {no application named "-bogus"}
  ---- Result should have been (exact matching):
  1 {bad option "-bogus": must be -async, -displayof, or --}
  ==== winSend-2.1 FAILED


  ==== winSend-2.1 Tk_SendObjCmd: arguments FAILED
  ==== Contents of test case:

      list [catch {send -async bogus foo} msg] $msg

  ---- Result was:
  1 {no application named "bogus"}
  ---- Result should have been (exact matching):
  1 {no registered server named "bogus"}
  ==== winSend-2.1 FAILED


  ==== winSend-2.1 Tk_SendObjCmd: arguments FAILED
  ==== Contents of test case:

      list [catch {send -displayof . bogus foo} msg] $msg

  ---- Result was:
  1 {option not implemented: "displayof" is not available
  for this platform.}
  ---- Result should have been (exact matching):
  1 {no registered server named "bogus"}
  ==== winSend-2.1 FAILED


  ==== winSend-2.1 Tk_SendObjCmd: arguments FAILED
  ==== Contents of test case:

      list [catch {send -- -bogus foo} msg] $msg

  ---- Result was:
  1 {no application named "-bogus"}
  ---- Result should have been (exact matching):
  1 {no registered server named "-bogus"}
  ==== winSend-2.1 FAILED


  ==== winSend-2.4 Tk_SendObjCmd - sending to ourselves
  in a different interp with
   errors FAILED
  ==== Contents of test case:

      newApp testApp
      list [catch {send testApp {expr 2 / 0}} msg] $msg
  $errorCode $errorInfo [int
  erp delete testApp]

  ---- Result was:
  1 {divide by zero} ARITH {divide by zeroDIVZERO
      invoked from within
  "send testApp {expr 2 / 0}"} {}
  ---- Result should have been (exact matching):
  1 {divide by zero} {ARITH DIVZERO {divide by zero}}
  {divide by zero
      while executing
  "expr 2 / 0"
      invoked from within
  "send testApp {expr 2 / 0}"} {}
  ==== winSend-2.4 FAILED


  ==== winSend-2.7 Tk_SendObjCmd - sending to another app
  - error FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      list [catch {send $interp {expr 2 / 0}} msg] $msg
  $errorCode $errorInfo

  ---- Result was:
  1 {divide by zero} ARITH {divide by zeroDIVZERO
      invoked from within
  "send $interp {expr 2 / 0}"}
  ---- Result should have been (exact matching):
  1 {divide by zero} {ARITH DIVZERO {divide by zero}}
  {divide by zero
      while executing
  "expr 2 / 0"
      invoked from within
  "send $interp {expr 2 / 0}"}
  ==== winSend-2.7 FAILED


  ==== winSend-3.1 TkGetInterpNames FAILED
  ==== Contents of test case:

      set origLength [llength $currentInterps]
      set newLength [llength [winfo interps]]
      expr {($newLength - 2) == $origLength}

  ---- Result was:
  0
  ---- Result should have been (exact matching):
  1
  ==== winSend-3.1 FAILED


  ==== winSend-6.1 SendDDEServer - XTYP_CONNECT FAILED
  ==== Contents of test case:

      set foo "Hello, World"
      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      set command "dde request Tk [tk appname] foo"
      list [catch "send \{$interp\} \{$command\}" msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  0 {Hello, World}
  ==== winSend-6.1 FAILED


  ==== winSend-6.2 SendDDEServer - XTYP_CONNECT_CONFIRM
  FAILED
  ==== Contents of test case:

      set foo "Hello, World"
      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      set command "dde request Tk [tk appname] foo"
      list [catch "send \{$interp\} \{$command\}" msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  0 {Hello, World}
  ==== winSend-6.2 FAILED


  ==== winSend-6.3 SendDDEServer - XTYP_DISCONNECT FAILED
  ==== Contents of test case:

      set foo "Hello, World"
      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      set command "dde request Tk [tk appname] foo"
      list [catch "send \{$interp\} \{$command\}" msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  0 {Hello, World}
  ==== winSend-6.3 FAILED


  ==== winSend-6.4 SendDDEServer - XTYP_REQUEST variable
  FAILED
  ==== Contents of test case:

      set foo "Hello, World"
      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      set command "dde request Tk [tk appname] foo"
      list [catch "send \{$interp\} \{$command\}" msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  0 {Hello, World}
  ==== winSend-6.4 FAILED


  ==== winSend-6.5 SendDDEServer - XTYP_REQUEST array FAILED
  ==== Contents of test case:

      catch {unset foo}
      set foo(test) "Hello, World"
      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      set command "dde request Tk [tk appname] foo(test)"
      list [catch "send \{$interp\} \{$command\}" msg]
  $msg [catch {unset foo}]

  ---- Result was:
  1 {invalid command name "dde"} 0
  ---- Result should have been (exact matching):
  0 {Hello, World} 0
  ==== winSend-6.5 FAILED


  ==== winSend-6.6 SendDDEServer - XTYP_REQUEST return
  results FAILED
  ==== Contents of test case:

      set foo 3
      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      set command "send [tk appname] {expr $foo + 1}"
      list [catch "send \{$interp\} \{$command\}" msg] $msg

  ---- Result was:
  1 {no application named "tktest"}
  ---- Result should have been (exact matching):
  0 4
  ==== winSend-6.6 FAILED


  ==== winSend-6.7 SendDDEServer - XTYP_EXECUTE FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      set command "send [tk appname] {expr 4 / 2}"
      list [catch "send \{$interp\} \{$command\}" msg] $msg

  ---- Result was:
  1 {no application named "tktest"}
  ---- Result should have been (exact matching):
  0 2
  ==== winSend-6.7 FAILED


  ==== winSend-6.8 SendDDEServer - XTYP_WILDCONNECT FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      set command "dde services Tk {}"
      list [catch "send \{$interp\} \{$command\}"]

  ---- Result was:
  1
  ---- Result should have been (exact matching):
  0
  ==== winSend-6.8 FAILED


  ==== winSend-9.1 SetDDEError FAILED
  ==== Contents of test case:

      list [catch {dde execute Tk foo {set foo hello}}
  msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {dde command failed}
  ==== winSend-9.1 FAILED


  ==== winSend-10.1 Tk_DDEObjCmd - wrong num args FAILED
  ==== Contents of test case:

      list [catch {dde} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {wrong # args: should be "dde ?-async? serviceName
  topicName value"}
  ==== winSend-10.1 FAILED


  ==== winSend-10.2 Tk_DDEObjCmd - unknown subcommand FAILED
  ==== Contents of test case:

      list [catch {dde foo} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {bad command "foo": must be execute, request, or
  services}
  ==== winSend-10.2 FAILED


  ==== winSend-10.3 Tk_DDEObjCmd - execute - wrong num
  args FAILED
  ==== Contents of test case:

      list [catch {dde execute} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {wrong # args: should be "dde execute ?-async?
  serviceName topicName value"}
  ==== winSend-10.3 FAILED


  ==== winSend-10.4 Tk_DDEObjCmd - execute - wrong num
  args FAILED
  ==== Contents of test case:

      list [catch {dde execute 3 4 5 6 7} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {wrong # args: should be "dde execute ?-async?
  serviceName topicName value"}
  ==== winSend-10.4 FAILED


  ==== winSend-10.5 Tk_DDEObjCmd - execute async - wrong
  num args FAILED
  ==== Contents of test case:

      list [catch {dde execute -async} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {wrong # args: should be "dde execute ?-async?
  serviceName topicName value"}
  ==== winSend-10.5 FAILED


  ==== winSend-10.6 Tk_DDEObjCmd - request - wrong num
  args FAILED
  ==== Contents of test case:

      list [catch {dde request} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {wrong # args: should be "dde request serviceName
  topicName value"}
  ==== winSend-10.6 FAILED


  ==== winSend-10.7 Tk_DDEObjCmd - services wrong num
  args FAILED
  ==== Contents of test case:

      list [catch {dde services} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {wrong # args: should be "dde services serviceName
  topicName"}
  ==== winSend-10.7 FAILED


  ==== winSend-10.8 Tk_DDEObjCmd - null service name FAILED
  ==== Contents of test case:

      list [catch {dde services {} {tktest #2}}]

  ---- Result was:
  1
  ---- Result should have been (exact matching):
  0
  ==== winSend-10.8 FAILED


  ==== winSend-10.9 Tk_DDEObjCmd - null topic name FAILED
  ==== Contents of test case:

      list [catch {dde services {Tk} {}}]

  ---- Result was:
  1
  ---- Result should have been (exact matching):
  0
  ==== winSend-10.9 FAILED


  ==== winSend-10.10 Tk_DDEObjCmd - execute - nothing to
  execute FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      list [catch {dde execute Tk $interp {}} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {cannot execute null data}
  ==== winSend-10.10 FAILED


  ==== winSend-10.11 Tk_DDEObjCmd - execute - no such
  conversation FAILED
  ==== Contents of test case:

      list [catch {dde execute Tk foo {set foo hello}}
  msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {dde command failed}
  ==== winSend-10.11 FAILED


  ==== winSend-10.12 Tk_DDEObjCmd - execute - async FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      list [catch {dde execute -async Tk $interp {set foo
  hello}} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  0 {}
  ==== winSend-10.12 FAILED


  ==== winSend-10.13 Tk_DDEObjCmd - execute FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      list [catch {dde execute Tk $interp {set foo
  goodbye}} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  0 {}
  ==== winSend-10.13 FAILED


  ==== winSend-10.14 Tk_DDEObjCmd - request - nothing to
  request FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      list [catch {dde request Tk $interp {}} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {cannot request value of null data}
  ==== winSend-10.14 FAILED


  ==== winSend-10.15 Tk_DDEObjCmd - request - invalid
  interp FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      list [catch {dde request Tk foo foo} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {dde command failed}
  ==== winSend-10.15 FAILED


  ==== winSend-10.16 Tk_DDEObjCmd - invalid variable FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      send $interp {unset foo}
      list [catch {dde request Tk $interp foo} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  1 {remote server cannot handle this command}
  ==== winSend-10.16 FAILED


  ==== winSend-10.17 Tk_DDEObjCmd - valid variable FAILED
  ==== Contents of test case:

      set newInterps [winfo interps]
      foreach interp $newInterps {
          if {[lsearch $currentInterps $interp] < 0} {
              break
          }
      }
      send $interp {set foo winSend-10.17}
      list [catch {dde request Tk $interp foo} msg] $msg

  ---- Result was:
  1 {invalid command name "dde"}
  ---- Result should have been (exact matching):
  0 winSend-10.17
  ==== winSend-10.17 FAILED


  ==== winSend-10.18 Tk_DDEObjCmd - services FAILED
  ==== Contents of test case:

      set currentService [list Tk [tk appname]]
      list [catch {dde services Tk {}} msg] [expr
  [lsearch $msg $currentService] >
  = 0]

  ---- Result was:
  1 0
  ---- Result should have been (exact matching):
  0 1
  ==== winSend-10.18 FAILED


tkt_uuid: 846143ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: misleading comments in tkWinSend.c
comment:
  Line 331 of tkWinSend.c says:

      /* FIX ME: async and check for local interp */

  There's also:

      /*
       * FIX ME: we don't support displayPtr.
       */

  and code like this:

      /*ThreadSpecificData *tsdPtr =
  TCL_TSD_INIT(&dataKey);*/

  Which suggest that tip150 was applied to the cvs head
  rather prematurely and should not be tagged 'final'.


tkt_uuid: 846884ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: textWind-10.6.1 fails
comment:
  Solaris 9 / CDE:

  ==== textWind-10.6.1 EmbWinLayoutProc procedure, error
  in creating window FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      catch {destroy .t2}
      .t window create 1.5 -create {
          toplevel .t2 -width 100 -height 150
          wm geom .t2 +0+0
          concat .t2
      }
      set msg {}
      update
      set msg

  ---- Result was:
  {{can't embed .t2 relative to .t}}
  ---- Result should have been (exact matching):
  {{can't embed .t2 relative to .t}} {{window name "t2"
  already exists in parent}}
  ==== textWind-10.6.1 FAILED


tkt_uuid: 848161ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 41. Photo Images
priority: 8
foundin: None
resolution: Accepted
title: Alpha blending patch
comment:
  This patch updates Tk_PhotoPutBlock() and 
  Tk_PhotoPutZoomedBlock() to:
    - copy source pixels instead of initializing destination to 
  0xd9 if destination is transparent,
    - update COMPLEX_ALPHA flag.


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: 852014ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 39. Image Basics
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Factor instance/master code
comment:
  It seems that all image managers (photo, bitmap, user
  defined types) really ought to have some sort of
  instance management code, but this isn't provided by
  Tk.  It seems like it would make sense to have this be
  part of the common Tk infrastructure instead of
  cut'n'pasted between implementations.


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: 852669ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 8
foundin: None
resolution: Fixed
title: Fix bugs #478568 and similar
comment:
  Fix tkWinFont.c:Tk_MeasureChars() to *not* measure each
  character in isolation.

  Todo: Fix Tk_DrawChars() to shift italic char runs to the
  right a bit.  Maybe use TextMetrics.tmOverhang for that.


tkt_uuid: 852949ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5a0
resolution: Fixed
title: Infinite loop in tabstop calculations
comment:
  To replicate the problem:

  pack [text .t -tabs "100 50"]
  .t insert end "a\tb\t"

  This locks up Tcl.  The root of the problem is that the
  last tab is smaller than the second-to-last tab, which
  makes tabArrayPtr->increment negative and the
  extrapolation loop in SizeOfTab() never terminates.


tkt_uuid: 852954ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5a0
resolution: Fixed
title: Text widget -[xy]scrollcommand changed meaning
comment:
  In Tk up to and including 8.4.5, the text widget's
  -xscrollcommand and -yscrollcommand options were
  interpreted as script prefixes and executed as per
  [eval]. In the current HEAD they are interpreted as
  command prefixes instead (i.e., substitutions aren't
  performed, comments and statement terminators not
  recognized, etc.).  

  This is an incompatible change; the old behaviour
  should be restored.

  It looks like this change occurred in revision 1.18 of
  tkText.c (the TIP 155 implementation).


tkt_uuid: 853003ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
foundin: obsolete: 8.5a0
resolution: Fixed
title: Performance problems in text widget
comment:
  Try the following:

  text .t
  for {set i 0} {$i < 10} { incr i } {
      .t delete 0.0 end
      puts [time {.t insert end [string repeat x [expr
  {$i*10000}]] ; update }]
  }


  With Tk 8.4, the time for each iteration is well under
  1 second, and scales approximately linearly.  With the
  current HEAD, the first iteration takes three orders of
  magnitude longer, and the time seems to go up
  quadratically.

  Oddly, if the text widget is [pack]ed first it's
  considerably faster, but still much slower than in 8.4.

  See also bug #231251 (re: bgerror dialog).


tkt_uuid: 853398ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 86. Test Tools
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: None
title: unixEmbed-5.1 EmbedFocusProc procedure, FocusIn events FAILE
comment:
  On Tru64Unix 5.1A with tk8.4.5 I get:

  $ ./tktest ../tests/unixEmbed.test -verbose e

  ==== unixEmbed-5.1 EmbedFocusProc procedure, FocusIn
  events FAILED
  ---- Result was:

  ---- Result should have been (exact matching):
  {focus in .t1}
  ==== unixEmbed-5.1 FAILED

  unixEmbed.test: Total   33      Passed  29      Skipped
  3       Failed  1
  Number of tests skipped for each constraint:
          3       nonPortable
  $


tkt_uuid: 853412ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Out of Date
title: scrolling incompatibilities
comment:
  [text] changes in the HEAD
  cause the arguments passed to
  the -yscrollcommand to have
  more precision than in prior Tk
  releases, and this can cause
  incompatibilities in existing scripts.

  One example is that AutoScroll
  detection is no longer working
  correctly in tkchat withTk 8.5.
  See tcllib Bug 849829.

  Whether the real bug is tkChat's
  or Tk 8.5's might need some
  more analysis, but if this change
  caught one script, it may well catch
  others.


tkt_uuid: 853414ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: None
title: Document undefined bindings
comment:
  The `bind` man page has always said, "Some of the
  substitutions are only valid for certain types of
  events; if they are used for other types of events the
  value substituted is undefined."  Donal has been
  tightening this up lately (8.4?), so that now invalid
  substitutions are guaranteed to yield {???} (true?).  I
  ask that we upgrade the documentation to reflect this.

  Donal believes Joe English is likely to be in a good
  position to review the idea.


tkt_uuid: 853643ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: None
title: Index script preference for debug Tk
comment:
  When both debug and non-debug Tk
  are installed, the generated index scripts
  allow either one to successfully [load]
  into tclsh.  Which one you get from a
  [package require Tk] is currently
  quasi-random, depending on the order
  in which [tclPkgUnknown] [source]s
  the pkgIndex.tcl files.

  This patch forces a preference for
  the debug-enabled Tk when Tcl
  is also debug-enabled.  David
  Gravereaux reports he finds this
  combination useful when stepping
  through Tcl/Tk applications.

  When Tcl is not debug-enabled,
  the choice for Tk remains
  quasi-random even after this patch,
  but that seems OK.  Either Tk will
  work, so either satisfies the 
  [package require].

  This patch changes only win/Makefile.
  If it is accepted, similar changes should
  be made to the alternative makefiles.


tkt_uuid: 854146ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Works For Me
title: focus is lost, preventing dialog interaction (8.5ok, 8.4bug)
comment:
  Here is a simple test case:

  ###
  toplevel .foo -class Dialog
  for {set i 0} {$i < 20} {incr i} {
      lappend items $i
  }
  message .foo.msg -text "Click on the popup\
    menu and make sure you select an item on\
    the menu which falls outside the bounding box\
    of this toplevel, so that when the menu\
    disappears your mouse is hovering over your\
    desktop (or some other app).  Then, without\
    doing anything else, try to click on the\
    button.  This fails!"
  pack .foo.msg -side top
  eval [list tk_optionMenu .foo.m menuvar] $items
  button .foo.b -text "Push" -command {
      tk_messageBox -message yes
      set done 1
  }
  pack .foo.m .foo.b -side left
  wm withdraw .foo
  update idletasks
  wm deiconify .foo
  grab .foo
  tkwait variable done
  grab release .foo
  ###

  On Windows (2000,XP at least), double click on a .tcl
  file containing the above.  You will see a new toplevel
  (dialog, effectively) containing a popup menu and a
  button, and a grab on the toplevel. The problem arises
  (it seems) that when you select an item from the popup,
  on releasing the mouse, the focus is lost and then when
  you move the mouse back over the window and over the
  "Push" button that button doesn't receive 'enter' or
  'leave' events, and the tk::Priv(window) variable is
  therefore not set, and so when you click on the button
  this block of code:

  if {$Priv(window) eq $w && [$w cget -state] ne
  "disabled"} {
      $w configure -state normal

      # Only invoke the command if it wasn't already
  invoked by the
      # auto-repeater functionality
      if { $Priv(repeated) == 0 } {
  uplevel #0 [list $w invoke]
      }
  }

  is never triggered, and so no action is invoked.

  Notice that if you select an item from the popup which
  happens to be on top of the underlying dialog, then
  everything works ok.

  If have no idea how to fix this at all, and don't know
  whether the button.tcl code should be more flexible
  about Priv(window) not being set, or whether the menu
  selection code should be better at setting the focus
  (esp. when there is a grab in place)...


tkt_uuid: 854178ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: textWind-7.* fail
comment:
  Using 2003-12-04 HEAD on Solaris 9/CDE:


  ==== textWind-7.1 EmbWinLostSlaveProc procedure FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 10 -height 20 -bg $color
      .t window create 1.2 -window .f
      update
      place .f -in .t -x 100 -y 50
      update
      list [winfo geom .f] [.t bbox 1.2]

  ---- Result was:
  10x20+105+55 {19 11 0 0}
  ---- Result should have been (exact matching):
  10x20+104+54 {19 11 0 0}
  ==== textWind-7.1 FAILED


  ==== textWind-7.2 EmbWinLostSlaveProc procedure FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .t.f -width 10 -height 20 -bg $color
      .t window create 1.2 -window .t.f
      update
      place .t.f -x 100 -y 50
      update
      list [winfo geom .t.f] [.t bbox 1.2]

  ---- Result was:
  10x20+105+55 {19 11 0 0}
  ---- Result should have been (exact matching):
  10x20+104+54 {19 11 0 0}
  ==== textWind-7.2 FAILED


tkt_uuid: 854437ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 56. [grab]
priority: 5 Medium
foundin: None
resolution: None
title: Bug involving grab, and menubuttons
comment:
  I found a bug that appears to be OS X specific.  I'm using 
  Mac OS X 10.2.8 and tcl/tk 8.4.5 that I compiled myself.  
  Admittedly, I haven't tried this on 8.4.5 on other OS's, but I 
  think I saw this bug in earlier OS X versions of tcl/tk, as 
  well.

  The code:

  console show
  set bleh Hi
  toplevel .a
  menubutton .a.mb -menu .a.mb.menu -textvariable ::bleh
  menu .a.mb.menu
  .a.mb.menu add radiobutton -variable ::bleh -label 1
  .a.mb.menu add radiobutton -variable ::bleh -label 2
  button .a.but1 -command "puts 1"
  button .a.but2 -command "puts 2"
  pack .a.mb .a.but1 .a.but2
  grab .a

  The bad behavior:

  Initially the two buttons work fine.  Now, pull down the 
  menubutton to either menu entry.  The next button you click 
  _will not_ work.  If you click on something else, the button 
  you clicked will function fine, again.  As a matter of fact, if 
  you click one button, then the other the second button you 
  click works fine.

  If you remove the "grab" line from the code, it works fine.


tkt_uuid: 856484ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Non-Latin scripts don't work
comment:
  On a German system Mac OS X 10.2.8 most scripts
  except latin don't work.  The "Unicode Label
  Demonstration" from demos/widget just shows
  garbage for all the interesting scripts.

  The reason is that macosx/tkMacOSXFont.c uses
  Quickdraw to draw text.  This depends on QuickDraw
  script codes and their support as primary scripts by
  fonts.  Although I have all fonts necessary for the
  scripts, they are not found by QuickDraw.

  In addition scripts that are not covered by the
  QuickDraw script list can't be supported at all.

  Patch #638966 can be used to fix this problem.


tkt_uuid: 857158ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 26. Conversions from String
priority: 5 Medium
foundin: obsolete: 8.4.5.1
resolution: Fixed
title: GetUid.3 glitch
comment:
  Eric Raymond reports a glitch
  in GetUid.3 at

  http://aspn.activestate.com/ASPN/Mail/Message/tcl-core/1911201


tkt_uuid: 857159ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 5 Medium
foundin: obsolete: 8.4.5.1
resolution: Fixed
title: CrtImgType.3 glitch
comment:
  Eric Raymond reports a glitch
  in CrtImgType.3 at:

  http://aspn.activestate.com/ASPN/Mail/Message/tcl-core/1911201


tkt_uuid: 858822ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 5 Medium
foundin: obsolete: 8.5a1
resolution: Duplicate
title: win-tk test suite hangs in 'send'
comment:
  Ever since the partial tip150 implementation was
  checked in, 'nmake -f makefile.vc TCLDIR=...... test'
  leads to the test suite hanging with an extra toplevel
  'tktest #N' hanging around. Examining my processes,
  there are two tktest.exe processes running and if I
  kill the extra one, the tests then run to completion.

  Older versions of Tk run the test suite fine.


tkt_uuid: 860307ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.4.5.1
resolution: Invalid
title: Remove ::tk::GetSelection?
comment:
  Now it seems that tkUnixSelect.c can handle UTF8_STRING
  selections (see change from 2002-09-30), is
  ::tk::GetSelection in tk.tcl still needed?


tkt_uuid: 860991ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: Fixed
title: Popup menu on Windows at wrong position
comment:
  On MS-Windows environment (NT,W2000,XP) popup menues
  which are too near to bottom or right screen edge are
  posted somewhere off the edge at a wrong place.

  Bug is in menu.tcl:  tk::PostOverPoint

  The fix mentioned there is wrong.

  See attached fixed version of menu.tcl


tkt_uuid: 861330ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: wish.exe cannot be loaded under WinXP
comment:
  It seems that Windows XP is particularly picky about
  the format of the version value in the manifest
  resource. It MUST be 4 numbers separated by dots (and
  maybe commas?). "8.5.a0" and "8.5.0" both result in an
  executable that Windows refuses to load. tktest is ok
  because it is not called wish.

  Bizzare.


tkt_uuid: 861777ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: None
title: Tk_MeasureChars bug?
comment:
  In the latest tk cvs head (with the updated
  Tk_MeasureChars), various tk tests now fail.  From the
  results it looks as if there's a bug that's been
  introduced.  For example, winfont-5.4 fails:

      .b.l config -wrap [expr $ax*6] -text "00000000"
      getsize

  This is a label that is set to wrap at a width of 6
  times the (monspace) character width.  However, the
  result shows that in fact 7 characters are fit onto the
  first line of the label. Here's a full test:

  toplevel .b
  wm geometry .b +0+0
  update idletasks

  set courier {Courier 14}
  set cx [font measure $courier 0]

  label .b.l -padx 0 -pady 0 -bd 0 -highlightthickness 0
  -justify left -text "0" -font systemfixed
  pack .b.l
  canvas .b.c -closeenough 0

  set t [.b.c create text 0 0 -anchor nw -just left -font
  $courier]
  pack .b.c
  update

  set ax [winfo reqwidth .b.l]
  set ay [winfo reqheight .b.l]
  proc getsize {} {
      update
      return "[winfo reqwidth .b.l] [winfo reqheight .b.l]"
  }

      .b.l config -wrap [expr $ax*6] -text "00000000"
      getsize

  # Should equal "[expr $ax*6] [expr $ay*2]"


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: 861840ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: Unicode support in windows and dialog titles and messages
comment:
  When using Japanese string in window title, dialog title or 
  dialog message (for save and open), the string gets 
  transformed to "????" or garbage.

  I have submitted patches to TkMacOSXDialog and 
  TkMacOSXWm that seem to fix these problems. They are 
  patches 861837 and 861839.


tkt_uuid: 862333ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 05. Canvas Items
priority: 4
foundin: None
resolution: Rejected
title: Render Scalable Vector Graphics
comment:
  Would you like to offer a programming interface for the library "http://librsvg.sourceforge.net/" to use it with "http://wiki.tcl.tk/canvas"? 

  Can the data structure "GdkPixbuf" be converted into a Tk image?


tkt_uuid: 862335ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: None
priority: 1 Zero
foundin: None
resolution: None
title: XForms - The Next Generation of Web Forms
comment:
  Would you like to render XForms-GUIs for more accessibility and comfort?
  - http://www.w3.org/MarkUp/Forms/
  - http://www.w3.org/WAI/
  - http://www.w3.org/TR/css3-ui/
  - http://www.xml.com/pub/a/2003/09/10/xforms.html


tkt_uuid: 862787ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: None
title: tcl script that writes to stdout and is called from wish thr
comment:
  A tcl script that writes to stdout and is called from wish 
  through exec does not return but just sits there and 
  consumes CPU cycles. This occurs when wish is started 
  by double clicking in the finder. The problem does not 
  occur when wish is started from the terminal like this:

  $ /Applications/Utilities/Wish 
  Shell.app/Contents/MacOS/Wish Shell

  To illustrate the problem, look at the following two little 
  scripts a.tcl and b.tcl:

  a.tcl:
  ---------------------------------
  #!/bin/sh
  # the next line restarts using tclsh \
  exec tclsh "$0" ${1+$@}

  if [catch {exec [file join [file dirname [info script]] 
  b.tcl]} error] {
   puts stderr $error
  }

  puts "end of a.tcl"
  ---------------------------------

  b.tcl:
  ---------------------------------
  #!/bin/sh
  # the next line restarts using tclsh \
  exec tclsh "$0" ${1+$@}

  puts "end of b.tcl"
  ---------------------------------

  When "a.tcl" is called from the command line the output 
  is

  end of a.tcl

  as expected. But when "a.tcl" is sourced from Wish 
  (either by source a.tcl or by using wish's menu item) 
  b.tcl gets called but never returns. It seems to be 
  related to the called script writing to stdout/stderr; 
  when the puts in "b.tcl" is removed everything works as 
  expected.

  Calling tclsh directly by putting "#!/usr/bin/tclsh" in the 
  first line instead of calling indirectly through sh does not 
  solve the problem.

  I am using Daniel Steffen's BI distribution of Tcl/Tk 8.4.4 
  on Mac OS X 10.3.1!


tkt_uuid: 862860ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: None
resolution: Invalid
title: Bizarreness in GetScreenFont()
comment:
  What on earth is going on inside the NT branch inside
  win/tkWinFont.c:GetScreenFont()

  Does LF_FACESIZE refer to the number of bytes or the
  number of characters (and is that including or
  excluding the U+0000 at the end) and why are we copying
  bytewise when we know the length of the string
  (Tcl_DStringLength will tell us)?  Surely we can just
  use memcpy() (and add the trailing U+0000, of course)
  like this:

    Tcl_UniChar *dst = (Tcl_UniChar *) lf.lfFaceName;
    memcpy(dst, Tcl_DStringValue(&ds),
            Tcl_DStringLength(&ds));
    dst[Tcl_DStringLength(&ds)/sizeof(Tcl_UniChar)] = 0;

  Who knows, perhaps this will be both faster and less
  buggy; see the recent thread on c.l.t for the reason
  for this bug report:
  http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=2e3f283.0312181501.38f68864%40posting.google.com&prev=/groups%3Fgroup%3Dcomp.lang.tcl%26hl%3Den

  I'm not entirely convinced that the non-NT branch is
  right either when things truncate (and why strcpy()
  when we know the length?) but I'll let the area
  maintainer deal with that.


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: 865082ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Introspect available photo write formats
comment:
  When writing a photo image to a file:

  $photo write $fileName -format $format

  the supported values for $format are
  determined by the run-time state of the
  interpreter (what packages are loaded,
  etc.)

  Given that, we should have a way to
  introspect the current list of acceptable
  values.


tkt_uuid: 865842ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: Accepted
title: Patch to fix Win32 disabled cascade menus
comment:
  There is a problem with disabled Win32 cascade menu
  items in Tk. Regular Windows application will show
  a gray right facing arrow for a cascade menu item
  that is disabled. Tk instead shows the little arrow
  painted black. This is really confusing because it
  makes the cascade look selectable.

  I have attached a file named menu.c that shows
  the Win32 code for an example menu. It demonstrates
  how Tk should operate. I have also attached a file
  named menu.tcl, it should look and function the
  same as the menu.c example, but it does not. If
  you open up the Tk version, you will see that the
  cascade menu item is drawn with a black color
  even though the cascade is disabled.

  The bug is actually in the Win32 code, it should
  draw the arrow gray. so we need to work around
  that. First, we avoid telling the OS that the
  Window is a popup type, that way it will not
  draw an arrow for us. Then, when we get
  the callback to draw the contents of the menu,
  we draw the arrow on our own. This is all made
  a little tricky because we don't know exactly
  where to put the arrow, and it is not the same
  on 95 vs XP systems, but the patch deals with
  those issues.


tkt_uuid: 866194ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 13. Win Menus
priority: 9 Immediate
foundin: None
resolution: Accepted
title: Fixup Win 95/XP menu look
comment:
  This patch fixes the look of disabled menu items under
  both XP and older Win systems. I recently checked in
  a patch that fixed the look under Win 95, but as
  far as I know disabled menu items have never looked
  quite right under XP. This patch does that while
  keeping the 95 look working.

  This patch will check the OS version to see if the
  user is running under XP or if they are using something
  older like 95/98/NT. This patch will also check to see
  if the "Windows Classic" theme is being used under
  XP.

  This patch adds a new private method called
  TkWinGetPlatformTheme(), it can be used to
  detect if we are running classic windows or
  the XP version (which has slightly different drawing
  rules).
  I don't think a change like this requires a TIP since
  it is really just fixing bugs in the current
  implementation.


tkt_uuid: 869305ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: None
title: phantom events with tk_popup
comment:
  with Tcl/Tk 8.4.2 on Microsoft Windows Platforms 
  the attached file "popup.tcl" will demonstrate 
  the generation of phantom events to unterlying 
  toplevel. 
   
  I verified this a least for the ButtonRelease 
  and BottonMotion type of events. 
   
  The BottonMotion events will always be generated, 
  the ButtonRelease only, if you hold Button-1 
  pressed while moving around in the popup. 
   
  I think these events should not be generated 
  (in fact they trigger false actions in my 
  programs), and in X11 they are correctly suppressed. 
   
  I also checked the "tk_popup" code in 
  lib/tk8.4.2/menu.tcl. Adding addional grabs there 
  help in the case of the Motion Events, but the 
  (most annoying) ButtonRelease keeps fooling me. 
   


tkt_uuid: 870281ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: Duplicate
title: Errors testing tk 8.4.5
comment:
  Hi,

  I compiled tk 8.4.5 without problem,
  but for the make test I got these errors :

  $ gmake test
  TCL_LIBRARY=/tmp/tcl8.4.5/library; export TCL_LIBRARY; \
  TK_LIBRARY=/tmp/tk8.4.5/library; export TK_LIBRARY; \
  ./tktest /tmp/tk8.4.5/unix/../tests/all.tcl -geometry
  +0+0 \
    
  Tests running in interp:  /tmp/tk8.4.5/unix/tktest
  Tests located in:  /tmp/tk8.4.5/tests
  Tests running in:  /tmp/tk8.4.5/unix
  Temporary files stored in /tmp/tk8.4.5/unix
  Test files sourced into current interpreter
  Running tests that match:  *
  Skipping test files that match:  l.*.test
  Only running test files that match:  *.test
  Tests began at Sun Jan 04 08:53:25 CET 2004
  bell.test
  Bell should ring now ...
  bgerror.test
  bind.test
   
  ==== bind-22.10 HandleEventGenerate FAILED
  ==== Contents of test case:
   
      setup
      bind .b.f <Key> {set x "%s %K"}
      set x {}
      event gen .b.f <Control-Key-1>
      set x
   
  ---- Result was:
  5 1
  ---- Result should have been (exact matching):
  4 1
  ==== bind-22.10 FAILED
   
  bitmap.test
  border.test
  button.test
  canvImg.test
  canvPs.test
  canvRect.test
  canvText.test
  canvWind.test
  canvas.test
  choosedir.test
  clipboard.test
  clrpick.test
  cmds.test
  color.test
  config.test
  cursor.test
  dialog.test
  embed.test
  entry.test
  event.test
  filebox.test
  focus.test
  focusTcl.test
  font.test
  frame.test
  geometry.test
  get.test
  grab.test
  grid.test
  id.test
  image.test
   
  ==== image-1.7 Tk_ImageCmd procedure, "create" option
  FAILED
  ==== Contents of test case:
   
      image delete myimage
      image create test myimage -variable x
      .c create image 100 50 -image myimage
      .c create image 100 150 -image myimage
      update
      set x {}
      image create test myimage -variable x
      update
      set x
   
  ---- Result was:
  {myimage free} {myimage free} {myimage delete} {myimage
  get} {myimage get} {myimage display 0 0 13 15 30 30}
  {myimage display 0 0 13 15 30 130}
  ---- Result should have been (exact matching):
  {myimage free} {myimage free} {myimage delete} {myimage
  get} {myimage get} {myimage display 0 0 30 15 30 30}
  {myimage display 0 0 30 15 30 130}
  ==== image-1.7 FAILED
   
   
  ==== image-1.8 Tk_ImageCmd procedure, "create" option
  FAILED
  ==== Contents of test case:
   
      .c delete all
      image create test myimage -variable x
      .c create image 100 50 -image myimage
      .c create image 100 150 -image myimage
      image delete myimage
      update
      set x {}
      image create test myimage -variable x
      update
      set x
   
  ---- Result was:
  {myimage get} {myimage get} {myimage display 0 0 13 15
  30 30} {myimage display 0 0 13 15 30 130}
  ---- Result should have been (exact matching):
  {myimage get} {myimage get} {myimage display 0 0 30 15
  30 30} {myimage display 0 0 30 15 30 130}
  ==== image-1.8 FAILED
   
  imgBmap.test
  imgPPM.test
  imgPhoto.test
  listbox.test
  macEmbed.test
  macFont.test
  macMenu.test
  macWinMenu.test
  macscrollbar.test
  main.test
  menu.test
  menuDraw.test
  menubut.test
  message.test
  msgbox.test
  obj.test
  oldpack.test
  option.test
  pack.test
  panedwindow.test
  place.test
  raise.test
  safe.test
  scale.test
  scrollbar.test
  select.test
  send.test
  spinbox.test
  text.test
  textBTree.test
  textDisp.test
  textImage.test
   
  ==== textImage-4.3 alignment and padding checking FAILED
  ==== Contents of test case:
   
      catch {
          image create photo small -width 5 -height 5
          small put red -to 0 0 4 4
          image create photo large -width 50 -height 50
          large put green -to 0 0 50 50
      }
      catch {destroy .t}
      text .t -font test_font -bd 0 -highlightthickness 0
  -padx 0 -pady 0
      pack .t
      .t image create end -image large
      .t image create end -image small -padx 5 -pady 10
      .t insert end test
      update
      set result ""
      lappend result default:[.t bbox small]
      foreach i {top bottom center baseline} {
          .t image configure small -align $i
          update
          lappend result $i:[.t bbox small]
      }
      set result
   
  ---- Result was:
  {default:55 22 5 5} {top:55 10 5 5} {bottom:55 35 5 5}
  {center:55 22 5 5} {baseline:55 23 5 5}
  ---- Result should have been (exact matching):
  {default:55 22 5 5} {top:55 10 5 5} {bottom:55 35 5 5}
  {center:55 22 5 5} {baseline:55 22 5 5}
  ==== textImage-4.3 FAILED
   
  textIndex.test
  textMark.test
  textTag.test
  textWind.test
  tk.test
  unixButton.test
  unixEmbed.test
  unixFont.test
  unixMenu.test
  unixSelect.test
  unixWm.test
   
  ==== 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+0+30
  ---- Result should have been (exact matching):
  100x150+0+0
  ==== unixWm-4.3 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
  ---- 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] 
  [winfo containing [expr $x + 450] $y]
   
  ---- Result was:
  .t.f .t.f .t {} {}
  ---- Result should have been (exact matching):
  .t .t.f .t.f.f .t {}
  ==== unixWm-50.8 FAILED
   
  util.test
   
  ==== util-1.3 Tk_GetScrollInfo procedure FAILED
  ==== Contents of test case:
   
      .l yview 0
      .l yview moveto .5
      .l yview
   
  ---- Result was:
  0.5 0.5
  ---- Result should have been (exact matching):
  0.5 0.75
  ==== util-1.3 FAILED
   
   
  ==== util-1.7 Tk_GetScrollInfo procedure FAILED
  ==== Contents of test case:
   
      .l yview 0
      .l yview scroll 2 pages
      .l nearest 0
   
  ---- Result was:
  2
  ---- Result should have been (exact matching):
  6
  ==== util-1.7 FAILED
   
   
  ==== util-1.8 Tk_GetScrollInfo procedure FAILED
  ==== Contents of test case:
   
      .l yview 15
      .l yview scroll -2 pages
      .l nearest 0
   
  ---- Result was:
  13
  ---- Result should have been (exact matching):
  9
  ==== util-1.8 FAILED
   
  visual.test
  visual_bb.test
  winButton.test
  winClipboard.test
  winDialog.test
  winFont.test
  winMenu.test
  winSend.test
  winWm.test
  window.test



  and then it timeouts...


tkt_uuid: 870844ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: None
title: WinTk: many menus in menubar won't popup
comment:
  The attached script recursively creates some submenus
  in a menubar.  Unfortunately, only the first menu
  actually pops up (in any of Tk 8.3/8.4/8.5), and
  attempting to launch two wish processes with this
  script simply fails (subsequent processes don't manage
  to launch, it seems).

  This is on WinXP

  catch {console show}

  proc mr {w count e} {
      for {set i 0} {$i < 5} {incr i} {
  if {$e} {
      $w insert end command \
        -label "entry$count$i" -command "foo $i"
  }
  if {$count > 0} {
      set m $w.m$count$i
      menu $m
      $w insert end cascade \
        -label "sub$count$i" -menu $m
      mr $m [expr {$count -1}] 1
  }
      }
  }
  proc foo {args} {
      puts stderr $args
  }

  menu .mb
  . configure -menu .mb
  mr .mb 5 0
  update


tkt_uuid: 872299ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: Access violation in tkBTreeFindPixelLine
comment:
  I got an access violation in tkTextBTree.c Line 1013
  tkBTreeFindPixelLine
  (nodePtr == NULL)

  after playing around in the debugger I recognized that

  nodePtr->numPixels == 0.

  so 'pixelsLef't is not decremented

  this code is called quit often until it crashes. But
  never nodePtr->numPixels was 0.

  The application is quit complex - so I did not know what
  tcl-code is actually called at this time.

  Here is the call-stack:

  TkBTreeFindPixelLine(TkTextBTree_ * 0x0c69ad48, int 0,
  int * 0x04252c80) line 1013 + 23 bytes
  TkTextMakePixelIndex(TkText * 0x0c69a8c0, int 0,
  TkTextIndex * 0x04252cac) line 323 + 20 bytes
  TkTextYviewCmd(TkText * 0x0c69a8c0, Tcl_Interp *
  0x04877c70, int 4, Tcl_Obj * const * 0x042530e0) line
  5211 + 28 bytes
  TextWidgetObjCmd(void * 0x0c69a8c0, Tcl_Interp *
  0x04877c70, int 4, Tcl_Obj * const * 0x042530e0) line
  1309 + 21 bytes
  TclEvalObjvInternal(Tcl_Interp * 0x04877c70, int 4,
  Tcl_Obj * const * 0x042530e0, const char * 0x0c5a71d0,
  int 57, int 0) line 3143 + 25 bytes
  Tcl_EvalEx(Tcl_Interp * 0x04877c70, const char *
  0x0c5a71d0, int 57, int 262144) line 3639 + 39 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x04877c70, Tcl_Obj *
  0x0c2e9c50, int 262144) line 3872 + 21 bytes
  Tcl_EvalObjCmd(void * 0x00000000, Tcl_Interp *
  0x04877c70, int 4, Tcl_Obj * const * 0x0487b59c) line
  681 + 18 bytes
  TclEvalObjvInternal(Tcl_Interp * 0x04877c70, int 4,
  Tcl_Obj * const * 0x0487b59c, const char * 0x00000000,
  int 0, int 0) line 3143 + 25 bytes
  TclExecuteByteCode(Tcl_Interp * 0x04877c70, ByteCode *
  0x0c514b40) line 1537 + 27 bytes
  TclCompEvalObj(Tcl_Interp * 0x04877c70, Tcl_Obj *
  0x053c8b50) line 1005 + 13 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x04877c70, Tcl_Obj *
  0x053c8b50, int 0) line 3884 + 13 bytes


tkt_uuid: 873608ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 7 High
foundin: obsolete: 8.5a2
resolution: Fixed
title: tearoff-menu: no Arrows for submenus (win)
comment:
  after tearing-off a menu with submenus the arrows on
  the right side of the entries disapear  Works for Unix
  (works for win in 8.4)


tkt_uuid: 873613ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 8
foundin: obsolete: 8.4.14
resolution: Fixed
title: tearoff-menus : can't select submenu twice (win)
comment:
  1. tearoff menu with submenus
  2. open submenu
  3. select entry in submenu (submenu disapear, function
  called)
  4. open submenu again ->  did not popup  !!!!!
   
  after opening another submenu I can open that submenu again

  Works fpr UNIX


tkt_uuid: 873655ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: None
title: Missing event when posting cascade menus
comment:
  Here is an example of the problem found under Linux:

  button .b
  pack .b
  .b configure -activebackground red
  menu .m
  menu .m.c
  .m add cascade -menu ".m.c" -label "cascade"
  .b configure -command {tk_popup .m [winfo rootx .b]
  [expr [winfo rooty .b] + [winfo height .b]]; .m
  activate 1; .m postcascade 1; tk_menuSetFocus .m}

  Use the mouse and click on the button and now move the
  mouse away.  You will see that the buttons state is not
  restored to normal and is left as active.  Without the
  postcascade as soon as you click on the button a
  <Leave> event is generated causing the button state to
  be restored to normal although the mouse is still
  within the widget.  Both of these behaviours appear to
  not be correct.

  I am unable to test the same conditions using
  menubutton as I can't see a way to post the cascade
  within the same event execution.  However menubutton is
  slightly different in that the <Leave> event is not
  generated until the mouse moves outside the widget.


tkt_uuid: 874745ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 7 High
foundin: obsolete: 8.5a0
resolution: Accepted
title: Tk accesses Tcl_*StartupScript*() which is private to Tcl
comment:
  DynamicLibrary /Users/espectro/tk/macosx/../../build/tk/
  Tk.framework/Versions/8.5/Tk 

  DynamicLibrary.LinkUsingFileList /Users/espectro/tk/macosx/
  ../../build/tk/Tk.framework/Versions/8.5/Tk 
      /usr/bin/gcc-3.3  -o /Users/espectro/tk/macosx/../../
  build/tk/Tk.framework/Versions/8.5/Tk   "-L/Users/espectro/
  tk/macosx/../../build/tk"  "-F/Users/espectro/tk/macosx/../
  ../build/tk" "-F/Users/espectro/tk/macosx/../../build/tcl"  
  -filelist /Users/espectro/tk/macosx/../../build/tk/
  Development.build/Wish.build/TkLibrary.build/Objects-
  normal/LinkFileList  "-framework" "Tcl" "-framework" 
  "Carbon" "-framework" "ApplicationServices"  "-arch" "ppc" 
  "-prebind" "-Wl,-single_module" "-dynamiclib" "-
  compatibility_version" "8.5" "-current_version" "8.5" "-
  seg1addr" "0xb000000" "-prebind"  -install_name "`echo "/
  Library/Frameworks/Tk.framework/Versions/8.5/Tk" | /usr/
  bin/sed 's!//*!/!g'`" 
  ld: warning prebinding disabled because of undefined 
  symbols
  ld: Undefined symbols:
  _TclUtfToUniChar
  /usr/bin/libtool: internal link edit command failed
  ...failed DynamicLibrary.LinkUsingFileList /Users/espectro/tk/
  macosx/../../build/tk/Tk.framework/Versions/8.5/Tk ...
  ** BUILD FAILED **
  make: *** [develop] Error 1

  8.4.5 compiles fine
  Using OSX Panther

  BTW, pbxbuild doesn't exist anymore. It's xcodebuild now


tkt_uuid: 877950ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 9 Immediate
foundin: obsolete: 8.4.5
resolution: Fixed
title: wish crash using [image]
comment:
  The following code does not make much sense, but it
  crashes wish8.4.5 for me (on linux) if called with the
  attached gif.

  set image [image create photo]
  $image read $argv
  $image copy $image \
      -from 0 0 [image width $image] [image height $image] \
      -to [expr {[image width $image] / 2}] 0

  Expected behavior: tcl error msg or TCL_OK (with
  whatever sideeffect on the picture), not seg fault.

  Valgrind says:
  ==26779== Invalid read of size 1
  ==26779==    at 0x402E8115: Tk_PhotoPutBlock
  (/home/rolf/tcltk/tk8.4.5/generic/tkImgPhoto.c:4340)
  ==26779==    by 0x402E85B9: Tk_PhotoPutZoomedBlock
  (/home/rolf/tcltk/tk8.4.5/generic/tkImgPhoto.c:4542)
  ==26779==    by 0x402E1B50: ImgPhotoCmd
  (/home/rolf/tcltk/tk8.4.5/generic/tkImgPhoto.c:887)
  ==26779==    by 0x403480A2: TclEvalObjvInternal
  (../generic/tclBasic.c:3087)
  ==26779==    Address 0x42C6D027 is not stack'd,
  malloc'd or free'd
  ==26779== 
  etc.


tkt_uuid: 879073ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Provide expected tab stop behavior
comment:
  This patch file is for Tk8.4.2.  It modifies
  generic/tkTextDisp.c.

  The problem is that the text widget has unusual tabbing
  behavior that doesn't match the expectations of users.
   The patch changes the tab stop behavior to match most
  user's expectations.

  Here is an example that demonstrates the strange
  behavior (note that '\t' means hit the Tab key, and
  '\n\ means hit the Enter or Return key):

  In "wish" create the text widget using:

  text .t -width 40 -height 20 -font {"Courier" 10} -tabs
  {30 left 60 90 120 150}
  pack .t

  Then set the focus on the text widget and type
  "\tx\tx\tx\tx\nxxxxx\tx\txx\tx\tx".  In the unpatched
  code you will see:
                                                        
                           
  bbbbxbbxbbxbbx
  xxxxxbxbxxbxbx

  As you can see (adjusting for proportional font
  distortions), the tabs are not moving the insertion
  point to the expected tab stops.

  After applying the patch, typing that same string yielded:

  bbbbxbbxbbxbbx
  xxxxxbxbbxxbxbbx

  This time, the tab stops are honored and the insertion
  points are where we expect them to be.

  NOTE: I did not invent this patch.  While search for a
  solution to the problem I found this patch given at
  this webpage:

  http://www.qs.co.nz/Tcl/TkTabs.html

  --
  Dave Hein


tkt_uuid: 879077ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Wont Fix
title: Text widget - unexpected tab stop behavior
comment:
  After typing some text, hitting the tab key does not
  always (hardly ever, in fact) move the insert point to
  the next tab stop.

  I've supplied a patch for generic/tkTextDisp.c that
  fixes the problem and gives the expected tabstop
  behavior.  The patch also gives an example so that you
  can reproduce the problem.

  Patch for 8.4.2 is  879073.  Let me know if you want me
  to produce patches for the latest version of Tk.

  --
  Dave Hein


tkt_uuid: 879175ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: Windows in front of all on Mac OS X
comment:
  I wish we can have a feature on Mac OS X to specify a 
  window to appeared "in front of all" windows of any app on 
  Mac OS X. Like a notify window or something like that.


tkt_uuid: 87ca68c7e69d57aae5d3c5024c160117b075f889
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 5 Medium
severity: Critical
foundin: 8.6
private_contact: d464e804f51be73b377a1a00aefb37a6b5a550f9
resolution: Works For Me
title: Modal window crashes tclsh on Mac OS X 10.8.4
comment:
  Tclsh crashes when a modal dialog is shown.
  Prerequisites: 
  Active State tcl8.6 for Mac
  Mac OS X 10.8.4 (12E55)

  Steps to reproduce:
  1. Run the attached script OR the DRAKON Editor 1.20 application
  (http://sourceforge.net/projects/drakon-editor/files/drakon_editor1.20.zip/download)
  2. Press any button that shows a modal dialog (for example "New diagram" or "Folder").
  3. Tclsh will crash

  Process:         tclsh8.6 [1212]
  Path:            /usr/local/bin/tclsh8.6
  Identifier:      tclsh8.6
  Version:         8.6.0 (8.6.0)
  Code Type:       X86-64 (Native)
  Parent Process:  bash [1058]
  User ID:         501

  Date/Time:       2013-07-19 12:03:00.922 +0400
  OS Version:      Mac OS X 10.8.4 (12E55)
  Report Version:  10

  Interval Since Last Report:          836218 sec
  Crashes Since Last Report:           28
  Per-App Crashes Since Last Report:   4
  Anonymous UUID:                      0D396B8D-272B-BB48-A7FA-14085E577AE8

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

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

  Application Specific Information:
  *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1000) creating window shape'
  abort() called
  terminate called throwing an exception

  Application Specific Backtrace 1:
  0   CoreFoundation                      0x00007fff89375b06 __exceptionPreprocess + 198
  1   libobjc.A.dylib                     0x00007fff853b63f0 objc_exception_throw + 43
  2   CoreFoundation                      0x00007fff893758dc +[NSException raise:format:] + 204
  3   AppKit                              0x00007fff8c84b9ff _NSCreateWindowWithOpaqueShape2 + 325
  4   AppKit                              0x00007fff8c84a340 -[NSWindow _commonAwake] + 2002
  5   AppKit                              0x00007fff8c8fa75b -[NSWindow _makeKeyRegardlessOfVisibility] + 88
  6   AppKit                              0x00007fff8c8fa6c5 -[NSWindow makeKeyAndOrderFront:] + 25
  7   Tk                                  0x0000000101dcc290 XMapWindow + 156
  8   Tk                                  0x0000000101d316e6 Tk_MapWindow + 89
  9   Tk                                  0x0000000101d3a859 MapFrame + 62
  10  Tcl                                 0x00000001000c0e96 TclServiceIdle + 76
  11  Tcl                                 0x00000001000a4857 Tcl_DoOneEvent + 329
  12  Tk                                  0x0000000101d15f68 Tk_MainLoop + 24
  13  Tcl                                 0x00000001000a0010 Tcl_MainEx + 2109
  14  tclsh8.6                            0x00000001000029b2 main + 56
  15  tclsh8.6                            0x0000000100002918 start + 52

  Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
  0   libsystem_kernel.dylib        	0x00007fff8e054212 __pthread_kill + 10
  1   libsystem_c.dylib             0x00007fff857f9b54 pthread_kill + 90
  2   libsystem_c.dylib             0x00007fff8583ddce abort + 143
  3   libc++abi.dylib               0x00007fff8465b9eb abort_message + 257
  4   libc++abi.dylib               0x00007fff8465939a default_terminate() + 28
  5   libobjc.A.dylib               0x00007fff853b6873 _objc_terminate() + 91
  6   libc++abi.dylib               0x00007fff846593c9 safe_handler_caller(void (*)()) + 8
  7   libc++abi.dylib               0x00007fff84659424 std::terminate() + 16
  8   libc++abi.dylib               0x00007fff8465a58b __cxa_throw + 111
  9   libobjc.A.dylib               0x00007fff853b650c objc_exception_throw + 327
  10  com.apple.CoreFoundation      	0x00007fff89409f49 -[NSException raise] + 9
  11  com.apple.AppKit              	0x00007fff8c84a1d0 -[NSWindow _commonAwake] + 1634
  12  com.apple.AppKit              	0x00007fff8c8fa75b -[NSWindow _makeKeyRegardlessOfVisibility] + 88
  13  com.apple.AppKit              	0x00007fff8c8fa6c5 -[NSWindow makeKeyAndOrderFront:] + 25
  14  Tk                            	0x0000000101dcc290 XMapWindow + 156
  15  Tk                            	0x0000000101d316e6 Tk_MapWindow + 89
  16  Tk                            	0x0000000101d3a859 MapFrame + 62
  17  Tcl                           0x00000001000c0e96 TclServiceIdle + 76
  18  Tcl                           0x00000001000a4857 Tcl_DoOneEvent + 329
  19  Tk                            	0x0000000101d15f68 Tk_MainLoop + 24
  20  Tcl                           0x00000001000a0010 Tcl_MainEx + 2109
  21  tclsh8.6                      	0x00000001000029b2 main + 56
  22  tclsh8.6                      	0x0000000100002918 start + 52

  Thread 1:: Dispatch queue: com.apple.libdispatch-manager
  0   libsystem_kernel.dylib        	0x00007fff8e054d16 kevent + 10
  1   libdispatch.dylib             0x00007fff8dd43dea _dispatch_mgr_invoke + 883
  2   libdispatch.dylib             0x00007fff8dd439ee _dispatch_mgr_thread + 54

  Thread 2:
  0   libsystem_kernel.dylib        	0x00007fff8e054322 __select + 10
  1   Tcl                           0x00000001000f1cbb NotifierThreadProc + 558
  2   libsystem_c.dylib             0x00007fff857f87a2 _pthread_start + 327
  3   libsystem_c.dylib             0x00007fff857e51e1 thread_start + 13

  Thread 3:
  0   libsystem_kernel.dylib        	0x00007fff8e0546d6 __workq_kernreturn + 10
  1   libsystem_c.dylib             0x00007fff857faf4c _pthread_workq_return + 25
  2   libsystem_c.dylib             0x00007fff857fad13 _pthread_wqthread + 412
  3   libsystem_c.dylib             0x00007fff857e51d1 start_wqthread + 13

  Thread 4:
  0   libsystem_kernel.dylib        	0x00007fff8e0546d6 __workq_kernreturn + 10
  1   libsystem_c.dylib             0x00007fff857faf4c _pthread_workq_return + 25
  2   libsystem_c.dylib             0x00007fff857fad13 _pthread_wqthread + 412
  3   libsystem_c.dylib             0x00007fff857e51d1 start_wqthread + 13

  Thread 0 crashed with X86 Thread State (64-bit):
    rax: 0x0000000000000000  rbx: 0x0000000000000006  rcx: 0x00007fff5fbfe378  rdx: 0x0000000000000000
    rdi: 0x0000000000000707  rsi: 0x0000000000000006  rbp: 0x00007fff5fbfe3a0  rsp: 0x00007fff5fbfe378
     r8: 0x00007fff71a36278   r9: 0x0000000000000006  r10: 0x0000000020000000  r11: 0x0000000000000206
    r12: 0x00007fff5fbfe500  r13: 0x0000000100a9a610  r14: 0x00007fff71a37180  r15: 0x00007fff5fbfe3e0
    rip: 0x00007fff8e054212  rfl: 0x0000000000000206  cr2: 0x00007fff71a2fff0
  Logical CPU: 0

  Binary Images:
         0x100000000 -        0x100002fff +tclsh8.6 (8.6.0 - 8.6.0) <89DAC27A-8C83-8E75-F699-25722A4BAA52> /usr/local/bin/tclsh8.6
         0x100005000 -        0x100132fef +Tcl (8.6.0 - 8.6.0) <16C07B11-77E6-B191-103C-3E6E05FE7988> /Library/Frameworks/Tcl.framework/Versions/8.6/Tcl
         0x10019b000 -        0x10019cff7  libCyrillicConverter.dylib (61) <D06971D7-9F16-3FE6-81E8-33E0FE4D6586> /System/Library/CoreServices/Encodings/libCyrillicConverter.dylib
         0x1007a5000 -        0x1007a8fef +libtkimg1.4.1.dylib (1.4.1) <DBA38FB7-6B63-F003-C83A-745FB411F824> /Library/Tcl/*/libtkimg1.4.1.dylib
         0x1007ac000 -        0x1007b0fff +libtkimgbmp1.4.1.dylib (1.4.1) <D5E295BF-95C8-615C-15AE-E181144CCABF> /Library/Tcl/*/libtkimgbmp1.4.1.dylib
         0x1007b3000 -        0x1007b8fe7 +libtkimggif1.4.1.dylib (1.4.1) <D2609F95-2C0F-4C45-DD07-F8727B0193C2> /Library/Tcl/*/libtkimggif1.4.1.dylib
         0x1007bb000 -        0x1007c0ff7 +libtkimgico1.4.1.dylib (1.4.1) <933683C2-CCEA-6EE2-8E35-0AB2E5874B68> /Library/Tcl/*/libtkimgico1.4.1.dylib
         0x1007c3000 -        0x1007c7fff +libtkimgjpeg1.4.1.dylib (1.4.1) <7C0F4ED6-CF45-8CA2-347B-B0F21219251B> /Library/Tcl/*/libtkimgjpeg1.4.1.dylib
         0x1007ca000 -        0x1007ceff7 +libtkimgpcx1.4.1.dylib (1.4.1) <8F7B1AB3-37A5-3197-694B-6209FC94268F> /Library/Tcl/*/libtkimgpcx1.4.1.dylib
         0x1007d1000 -        0x1007d8fff +libtkimgpixmap1.4.1.dylib (1.4.1) <956B95BD-EA2F-3619-BE2F-B8BA623262BF> /Library/Tcl/*/libtkimgpixmap1.4.1.dylib
         0x1007db000 -        0x1007f5ff7 +libzlibtcl1.2.7.dylib (1.2.7) <855F1A4E-220A-D0D9-D3DF-955F7BCB40B8> /Library/Tcl/*/libzlibtcl1.2.7.dylib
         0x1007f9000 -        0x1007fcff7 +libtkimgpng1.4.1.dylib (1.4.1) <C52C599C-0865-C283-6A6A-EA34F5CCA885> /Library/Tcl/*/libtkimgpng1.4.1.dylib
         0x101883000 -        0x1018d0fff +libjpegtcl8.3.dylib (8.3) <9BF83CD4-B227-F6C8-5DD9-628F26AF9E78> /Library/Tcl/*/libjpegtcl8.3.dylib
         0x1018d8000 -        0x1018ddff7 +libtkimgppm1.4.1.dylib (1.4.1) <C271EA24-ECCF-A604-E669-3E907B30EB00> /Library/Tcl/*/libtkimgppm1.4.1.dylib
         0x1018e0000 -        0x1018e3ff7 +libtkimgps1.4.1.dylib (1.4.1) <2CC5E272-A58F-D155-4D48-6C76CF5FFC6D> /Library/Tcl/*/libtkimgps1.4.1.dylib
         0x1018e6000 -        0x1018ecff7 +libtkimgsgi1.4.1.dylib (1.4.1) <3C92A167-D60D-3568-9B7D-29BB0692A5EB> /Library/Tcl/*/libtkimgsgi1.4.1.dylib
         0x1018ef000 -        0x1018f4fff +libtkimgsun1.4.1.dylib (1.4.1) <C73BEC82-73A8-38C8-7443-9771ACAF05A2> /Library/Tcl/*/libtkimgsun1.4.1.dylib
         0x1018f7000 -        0x1018fbfff +libtkimgtga1.4.1.dylib (1.4.1) <43A2D36B-A7DD-E058-7DAF-DEE5445254A2> /Library/Tcl/*/libtkimgtga1.4.1.dylib
         0x101d00000 -        0x101e1afe7 +Tk (8.6.0 - 8.6.0) <DAA87C08-C49D-EFA4-DD71-ED7DE1443A69> /Library/Frameworks/Tk.framework/Versions/8.6/Tk
         0x101f05000 -        0x101f34fef +libpngtcl1.4.12.dylib (1.4.12) <BEDDF33D-E6A9-E83F-36E7-8DC7A2F94F8A> /Library/Tcl/*/libpngtcl1.4.12.dylib
         0x101f3b000 -        0x101f81ff7  libtifftcl3.9.4.dylib (97.1) <B269CDB9-3348-35BA-A5E2-17CAEC4843A8> /System/Library/Tcl/8.5/Img1.4/libtifftcl3.9.4.dylib
         0x101f8d000 -        0x101f9dff7 +libtkimgtiff1.4.1.dylib (1.4.1) <647D2C7F-503A-BFCD-E1E0-0FDFECA27405> /Library/Tcl/*/libtkimgtiff1.4.1.dylib
         0x101fa2000 -        0x101fa7ff7 +libtkimgwindow1.4.1.dylib (1.4.1) <020EB9FD-C0D4-B215-0150-773172E176AF> /Library/Tcl/*/libtkimgwindow1.4.1.dylib
         0x101faa000 -        0x101fadff7 +libtkimgxbm1.4.1.dylib (1.4.1) <56EA2E5B-1E72-C921-0D18-62057C647BDA> /Library/Tcl/*/libtkimgxbm1.4.1.dylib
         0x101fb0000 -        0x101fb4fff +libtkimgxpm1.4.1.dylib (1.4.1) <9482F4FE-DC0F-2540-F749-40BC197F83BC> /Library/Tcl/*/libtkimgxpm1.4.1.dylib
         0x103161000 -        0x1031fffff +libsqlite3.7.15.2.dylib (3.7.15) <2C939015-3CB5-0634-1636-1AD6F5F3CF6B> /Library/Tcl/*/libsqlite3.7.15.2.dylib
      0x7fff661cb000 -     0x7fff661ff93f  dyld (210.2.3) <A40597AA-5529-3337-8C09-D8A014EB1578> /usr/lib/dyld
      0x7fff8111a000 -     0x7fff813ebff7  com.apple.security (7.0 - 55179.13) <F428E306-C407-3B55-BA82-E58755E8A76F> /System/Library/Frameworks/Security.framework/Versions/A/Security
      0x7fff823ac000 -     0x7fff823cbff7  com.apple.ChunkingLibrary (2.0 - 133.3) <8BEC9AFB-DCAA-37E8-A5AB-24422B234ECF> /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary
      0x7fff823dd000 -     0x7fff82446fff  libstdc++.6.dylib (56) <08A26E98-26A7-3A23-A594-01EF923BA123> /usr/lib/libstdc++.6.dylib
      0x7fff82d44000 -     0x7fff82d88fff  libcups.2.dylib (327.6) <9C01D012-6F4C-3B69-B614-1B408B0ED4E3> /usr/lib/libcups.2.dylib
      0x7fff82d89000 -     0x7fff82dbffff  com.apple.DebugSymbols (98 - 98) <7059F71D-9A82-3D32-99BB-E043DEDA6174> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols
      0x7fff82f32000 -     0x7fff82f35fff  com.apple.help (1.3.2 - 42) <418A9A41-BCB4-32A2-97ED-3A388F69CA9D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
      0x7fff82f36000 -     0x7fff82f58ff7  com.apple.Kerberos (2.0 - 1) <416543F5-E7AF-3269-843F-C8CDA8DD0FFA> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
      0x7fff8380f000 -     0x7fff8380fffd  com.apple.audio.units.AudioUnit (1.9 - 1.9) <EC55FB59-2443-3F08-9142-7BCC93C76E4E> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
      0x7fff83816000 -     0x7fff8381cfff  libmacho.dylib (829) <BF332AD9-E89F-387E-92A4-6E1AB74BD4D9> /usr/lib/system/libmacho.dylib
      0x7fff83c41000 -     0x7fff83ca4ff7  com.apple.audio.CoreAudio (4.1.1 - 4.1.1) <9ACD3AED-6C04-3BBB-AB2A-FC253B16D093> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
      0x7fff83cda000 -     0x7fff83cdefff  libCGXType.A.dylib (332) <17C8DD17-B3CB-3633-B252-C368AE51204C> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib
      0x7fff83cdf000 -     0x7fff83d61ff7  com.apple.Heimdal (3.0 - 2.0) <C94B0C6C-1320-35A1-8143-FE252E7B2A08> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal
      0x7fff83d62000 -     0x7fff83db9ff7  com.apple.ScalableUserInterface (1.0 - 1) <93C14595-6172-37E9-88F2-CBC80A1C54D0> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface
      0x7fff83dba000 -     0x7fff83dbffff  libcache.dylib (57) <65187C6E-3FBF-3EB8-A1AA-389445E2984D> /usr/lib/system/libcache.dylib
      0x7fff83de9000 -     0x7fff83e3aff7  com.apple.SystemConfiguration (1.12.2 - 1.12.2) <A4341BBD-A330-3A57-8891-E9C1A286A72D> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
      0x7fff83e3b000 -     0x7fff83fb0ff7  com.apple.CFNetwork (596.4.3 - 596.4.3) <A57B3308-2F08-3EC3-B4AC-39A3D9F0B9F7> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
      0x7fff844b9000 -     0x7fff844bdff7  com.apple.CommonPanels (1.2.5 - 94) <5F81D593-4B87-3DCC-B934-625D436B4CB1> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
      0x7fff844fb000 -     0x7fff84555fff  com.apple.print.framework.PrintCore (8.3 - 387.2) <5BA0CBED-4D80-386A-9646-F835C9805B71> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
      0x7fff84556000 -     0x7fff84561fff  libsystem_notify.dylib (98.5) <C49275CC-835A-3207-AFBA-8C01374927B6> /usr/lib/system/libsystem_notify.dylib
      0x7fff84562000 -     0x7fff84562fff  com.apple.vecLib (3.8 - vecLib 3.8) <794317C7-4E38-338A-A874-5E18001C8503> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
      0x7fff84563000 -     0x7fff84628ff7  com.apple.coreui (2.0 - 181.1) <7C4196D5-79E8-3557-963B-71F494DC9B04> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
      0x7fff84629000 -     0x7fff8464aff7  libCRFSuite.dylib (33) <B49DA255-A4D9-33AF-95AB-B319570CDF7B> /usr/lib/libCRFSuite.dylib
      0x7fff84658000 -     0x7fff8467dff7  libc++abi.dylib (26) <D86169F3-9F31-377A-9AF3-DB17142052E4> /usr/lib/libc++abi.dylib
      0x7fff846cf000 -     0x7fff84769fff  libvMisc.dylib (380.6) <714336EA-1C0E-3735-B31C-19DFDAAF6221> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
      0x7fff8476a000 -     0x7fff84772ff7  libsystem_dnssd.dylib (379.38.1) <BDCB8566-0189-34C0-9634-35ABD3EFE25B> /usr/lib/system/libsystem_dnssd.dylib
      0x7fff84773000 -     0x7fff84794fff  com.apple.Ubiquity (1.2 - 243.15) <C9A7EE77-B637-3676-B667-C0843BBB0409> /System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Ubiquity
      0x7fff84795000 -     0x7fff8479afff  com.apple.OpenDirectory (10.8 - 151.10) <1F47EC96-7403-3690-8D8D-C31D3B6FDA0A> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
      0x7fff848d8000 -     0x7fff848e3fff  com.apple.CommonAuth (3.0 - 2.0) <7A953C1F-8B18-3E46-9BEA-26D9B5B7745D> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
      0x7fff848e4000 -     0x7fff848ebfff  libGFXShared.dylib (8.9.2) <398F8D57-EC82-3E13-AC8E-470BE19237D7> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
      0x7fff848ec000 -     0x7fff84992ff7  com.apple.CoreServices.OSServices (557.6 - 557.6) <1BDB5456-0CE9-301C-99C1-8EFD0D2BFCCD> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
      0x7fff849a3000 -     0x7fff849affff  libCSync.A.dylib (332) <47466CF6-EB5C-3312-9E24-178F4410A92B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
      0x7fff84adb000 -     0x7fff84b1eff7  com.apple.RemoteViewServices (2.0 - 80.6) <5CFA361D-4853-3ACC-9EFC-A2AC1F43BA4B> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices
      0x7fff84b1f000 -     0x7fff84b36fff  libGL.dylib (8.9.2) <B8E5948D-BCF2-3727-B74E-D74B8EDC82D6> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
      0x7fff84bcc000 -     0x7fff84c09fef  libGLImage.dylib (8.9.2) <C38649ED-E1C9-315E-9953-F33E8C6A3C89> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
      0x7fff84c26000 -     0x7fff84c3dfff  com.apple.GenerationalStorage (1.1 - 132.3) <FD4A84B3-13A8-3C60-A59E-25A361447A17> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage
      0x7fff84cbf000 -     0x7fff84cc0fff  liblangid.dylib (116) <864C409D-D56B-383E-9B44-A435A47F2346> /usr/lib/liblangid.dylib
      0x7fff84cc1000 -     0x7fff84cedff7  libRIP.A.dylib (332) <D26BC320-B415-3C4D-B57F-D525FC361BB2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
      0x7fff84cee000 -     0x7fff84d15fff  com.apple.framework.familycontrols (4.1 - 410) <50F5A52C-8FB6-300A-977D-5CFDE4D5796B> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls
      0x7fff84d16000 -     0x7fff84e36fff  com.apple.desktopservices (1.7.4 - 1.7.4) <ED3DA8C0-160F-3CDC-B537-BF2E766AB7C1> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
      0x7fff84e37000 -     0x7fff84f2cfff  libiconv.2.dylib (34) <FEE8B996-EB44-37FA-B96E-D379664DEFE1> /usr/lib/libiconv.2.dylib
      0x7fff84f56000 -     0x7fff84f5dfff  libcopyfile.dylib (89) <876573D0-E907-3566-A108-577EAD1B6182> /usr/lib/system/libcopyfile.dylib
      0x7fff84f5e000 -     0x7fff84f5ffff  libsystem_blocks.dylib (59) <D92DCBC3-541C-37BD-AADE-ACC75A0C59C8> /usr/lib/system/libsystem_blocks.dylib
      0x7fff84f8c000 -     0x7fff84fcfff7  com.apple.bom (12.0 - 192) <0EFE0F2D-B6DE-3D1E-93C2-EED6D96F70A2> /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom
      0x7fff84fd7000 -     0x7fff85072fff  com.apple.CoreSymbolication (3.0 - 117) <C304FDB8-2FF7-34BC-858A-2B96C2B039D5> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
      0x7fff850d0000 -     0x7fff850fbfff  libxslt.1.dylib (11.3) <441776B8-9130-3893-956F-39C85FFA644F> /usr/lib/libxslt.1.dylib
      0x7fff8521d000 -     0x7fff85285ff7  libc++.1.dylib (65.1) <E5A0C88E-0837-3015-A987-F8C5A0D35DD6> /usr/lib/libc++.1.dylib
      0x7fff85286000 -     0x7fff85288fff  com.apple.securityhi (4.0 - 55002) <8B2008A2-B6A2-3E69-9FA2-77B38C869DD6> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
      0x7fff852d1000 -     0x7fff853a3ff7  com.apple.CoreText (260.0 - 275.16) <990F3C7D-EEF1-33C4-99D6-8E81C96ED3E3> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
      0x7fff853a4000 -     0x7fff853a4fff  com.apple.Cocoa (6.7 - 19) <3CFC90D2-2BE9-3E5C-BFDB-5E161A2C2B29> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
      0x7fff853a5000 -     0x7fff854bd92f  libobjc.A.dylib (532.2) <90D31928-F48D-3E37-874F-220A51FD9E37> /usr/lib/libobjc.A.dylib
      0x7fff854c9000 -     0x7fff85677fff  com.apple.QuartzCore (1.8 - 304.3) <F450F2DE-2F24-3557-98B6-310E05DAC17F> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
      0x7fff85708000 -     0x7fff8575dff7  libTIFF.dylib (850) <EDAF0D99-70AF-3B3F-9EFA-9463C91D0E3C> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
      0x7fff8575e000 -     0x7fff85773fff  com.apple.ImageCapture (8.0 - 8.0) <71B24609-DEE9-3927-9C82-62E72270299C> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
      0x7fff85774000 -     0x7fff8579bff7  com.apple.PerformanceAnalysis (1.16 - 16) <1BDA3662-18B7-3F38-94E5-9ACD477A7682> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis
      0x7fff857e4000 -     0x7fff858b0ff7  libsystem_c.dylib (825.26) <4C9EB006-FE1F-3F8F-8074-DFD94CF2CE7B> /usr/lib/system/libsystem_c.dylib
      0x7fff8590e000 -     0x7fff85925fff  com.apple.CFOpenDirectory (10.8 - 151.10) <FFBBA538-00B5-334E-BA5B-C8AD6CDCDA14> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
      0x7fff85926000 -     0x7fff85926fff  com.apple.ApplicationServices (45 - 45) <5302CC85-D534-3FE5-9E56-CA16762177F6> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
      0x7fff85927000 -     0x7fff85933fff  com.apple.CrashReporterSupport (10.8.3 - 418) <DE6AFE16-D97E-399D-82ED-3522C773C36E> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport
      0x7fff85934000 -     0x7fff85942fff  com.apple.Librarian (1.1 - 1) <5AC28666-7642-395F-A923-C6F8A274BBBD> /System/Library/PrivateFrameworks/Librarian.framework/Versions/A/Librarian
      0x7fff8598f000 -     0x7fff8599dff7  libkxld.dylib (2050.24.15) <A619A9AC-09AF-3FF3-95BF-F07CC530EC31> /usr/lib/system/libkxld.dylib
      0x7fff859eb000 -     0x7fff85a45ff7  com.apple.opencl (2.2.19 - 2.2.19) <3C7DFB2C-B3F9-3447-A1FC-EAAA42181A6E> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
      0x7fff85a46000 -     0x7fff85a5cfff  com.apple.MultitouchSupport.framework (235.29 - 235.29) <617EC8F1-BCE7-3553-86DD-F857866E1257> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
      0x7fff85ab7000 -     0x7fff85ab7fff  libkeymgr.dylib (25) <CC9E3394-BE16-397F-926B-E579B60EE429> /usr/lib/system/libkeymgr.dylib
      0x7fff85b1a000 -     0x7fff85b1cff7  com.apple.print.framework.Print (8.0 - 258) <8F243E49-021F-3892-B555-3010A7F450A2> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
      0x7fff85b89000 -     0x7fff85b8dfff  libCoreVMClient.dylib (32.3) <AD8391D9-56DD-3A78-A294-6A30E6ECE1A2> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
      0x7fff85b8e000 -     0x7fff85b91ff7  libdyld.dylib (210.2.3) <F59367C9-C110-382B-A695-9035A6DD387E> /usr/lib/system/libdyld.dylib
      0x7fff85c6a000 -     0x7fff85c79fff  com.apple.opengl (1.8.9 - 1.8.9) <6FD163A7-16CC-3D1F-B4B5-B0FDC4ADBF79> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
      0x7fff85d6c000 -     0x7fff85e1dfff  com.apple.LaunchServices (539.9 - 539.9) <07FC6766-778E-3479-8F28-D2C9917E1DD1> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
      0x7fff85e1e000 -     0x7fff85e29ff7  com.apple.bsd.ServiceManagement (2.0 - 2.0) <C12962D5-85FB-349E-AA56-64F4F487F219> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
      0x7fff85e2a000 -     0x7fff85e2efff  libpam.2.dylib (20) <C8F45864-5B58-3237-87E1-2C258A1D73B8> /usr/lib/libpam.2.dylib
      0x7fff85e2f000 -     0x7fff85e34fff  libcompiler_rt.dylib (30) <08F8731D-5961-39F1-AD00-4590321D24A9> /usr/lib/system/libcompiler_rt.dylib
      0x7fff85e35000 -     0x7fff85e48ff7  com.apple.LangAnalysis (1.7.0 - 1.7.0) <023D909C-3AFA-3438-88EB-05D0BDA5AFFE> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
      0x7fff86091000 -     0x7fff860e7fff  com.apple.HIServices (1.20 - 417) <A1129272-FEC8-350B-BA26-5A97F23C413D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
      0x7fff860fd000 -     0x7fff8610bff7  libsystem_network.dylib (77.10) <2AAA67A1-525E-38F0-8028-1D2B64716611> /usr/lib/system/libsystem_network.dylib
      0x7fff8610c000 -     0x7fff86112fff  com.apple.DiskArbitration (2.5.2 - 2.5.2) <C713A35A-360E-36CE-AC0A-25C86A3F50CA> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
      0x7fff86273000 -     0x7fff86311ff7  com.apple.ink.framework (10.8.2 - 150) <3D8D16A2-7E01-3EA1-B637-83A36D353308> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
      0x7fff8632d000 -     0x7fff86340ff7  libbsm.0.dylib (32) <F497D3CE-40D9-3551-84B4-3D5E39600737> /usr/lib/libbsm.0.dylib
      0x7fff863b0000 -     0x7fff863b4fff  com.apple.IOSurface (86.0.4 - 86.0.4) <26F01CD4-B76B-37A3-989D-66E8140542B3> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
      0x7fff863b5000 -     0x7fff863bbff7  libunwind.dylib (35.1) <21703D36-2DAB-3D8B-8442-EAAB23C060D3> /usr/lib/system/libunwind.dylib
      0x7fff863bc000 -     0x7fff8671bfff  com.apple.Foundation (6.8 - 945.18) <1D7E58E6-FA3A-3CE8-AC85-B9D06B8C0AA0> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
      0x7fff86f02000 -     0x7fff87232fff  com.apple.HIToolbox (2.0 - 626.1) <656D08C2-9068-3532-ABDD-32EC5057CCB2> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
      0x7fff87233000 -     0x7fff87233fff  com.apple.CoreServices (57 - 57) <45F1466A-8264-3BB7-B0EC-E5E5BFBED143> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
      0x7fff8727b000 -     0x7fff8728aff7  libxar.1.dylib (105) <B6A7C8AA-3E20-3A1D-A7BA-4FD0052FA508> /usr/lib/libxar.1.dylib
      0x7fff873c5000 -     0x7fff873c6ff7  libSystem.B.dylib (169.3) <EFACA0C5-1AC6-3F93-9E02-147D4B0A0112> /usr/lib/libSystem.B.dylib
      0x7fff873c7000 -     0x7fff873c8ff7  libremovefile.dylib (23.2) <6763BC8E-18B8-3AD9-8FFA-B43713A7264F> /usr/lib/system/libremovefile.dylib
      0x7fff873c9000 -     0x7fff873c9fff  com.apple.Carbon (154 - 155) <372716D2-6FA1-3611-8501-3DD1D4A6E8C8> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
      0x7fff87667000 -     0x7fff87764ff7  libxml2.2.dylib (22.3) <7FD09F53-83DA-3ECD-8DD9-870E1A2F0427> /usr/lib/libxml2.2.dylib
      0x7fff879dd000 -     0x7fff87b78fef  com.apple.vImage (6.0 - 6.0) <FAE13169-295A-33A5-8E6B-7C2CC1407FA7> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
      0x7fff87b98000 -     0x7fff885284af  com.apple.CoreGraphics (1.600.0 - 332) <5AB32E51-9154-3733-B83B-A9A748652847> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
      0x7fff88529000 -     0x7fff88946fff  FaceCoreLight (2.4.1) <A34C9575-C4C1-31B1-809B-7751070B4E8B> /System/Library/PrivateFrameworks/FaceCoreLight.framework/Versions/A/FaceCoreLight
      0x7fff88947000 -     0x7fff88949fff  libCVMSPluginSupport.dylib (8.9.2) <EF1192AC-3357-3A0B-BFAF-6594D7737892> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib
      0x7fff88a3c000 -     0x7fff88a3cfff  libOpenScriptingUtil.dylib (148.3) <F8681222-0969-3B10-8BCE-C55A4B9C520C> /usr/lib/libOpenScriptingUtil.dylib
      0x7fff88a8f000 -     0x7fff88aebff7  com.apple.Symbolication (1.3 - 93) <D9DBF413-34C7-3BC5-A0A6-81C06BA9FB62> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication
      0x7fff88aec000 -     0x7fff88af0fff  libGIF.dylib (850) <D4525F87-759C-338C-B283-BB8DE815D3D5> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
      0x7fff88af1000 -     0x7fff88c0afff  com.apple.ImageIO.framework (3.2.1 - 850) <C3FFCEEB-AA0C-314B-9E94-7005EE48A403> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
      0x7fff88e02000 -     0x7fff88e04ff7  libunc.dylib (25) <2FDC94A7-3039-3680-85F3-2164E63B464D> /usr/lib/system/libunc.dylib
      0x7fff88e05000 -     0x7fff88f10fff  libFontParser.dylib (84.6) <96C42E49-79A6-3475-B5E4-6A782599A6DA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
      0x7fff88f11000 -     0x7fff88f70fff  com.apple.AE (645.6 - 645.6) <44F403C1-660A-3543-AB9C-3902E02F936F> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
      0x7fff88f71000 -     0x7fff88f73fff  libquarantine.dylib (52.1) <143B726E-DF47-37A8-90AA-F059CFD1A2E4> /usr/lib/system/libquarantine.dylib
      0x7fff88f74000 -     0x7fff88f86ff7  libz.1.dylib (43) <2A1551E8-A272-3DE5-B692-955974FE1416> /usr/lib/libz.1.dylib
      0x7fff88f91000 -     0x7fff88f9efff  com.apple.AppleFSCompression (49 - 1.0) <E616053D-D3C2-3600-B8DF-A5E0D9665634> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
      0x7fff88f9f000 -     0x7fff8900dff7  com.apple.framework.IOKit (2.0.1 - 755.24.1) <04BFB138-8AF4-310A-8E8C-045D8A239654> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
      0x7fff8900e000 -     0x7fff8903fff7  com.apple.DictionaryServices (1.2 - 184.4) <2EC80C71-263E-3D63-B461-6351C876C50D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
      0x7fff89040000 -     0x7fff89040fff  com.apple.Accelerate (1.8 - Accelerate 1.8) <6AD48543-0864-3D40-80CE-01F184F24B45> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
      0x7fff8915a000 -     0x7fff89168fff  libcommonCrypto.dylib (60027) <BAAFE0C9-BB86-3CA7-88C0-E3CBA98DA06F> /usr/lib/system/libcommonCrypto.dylib
      0x7fff89169000 -     0x7fff891d1fff  libvDSP.dylib (380.6) <CD4C5EEB-9E63-30C4-8103-7A5EAEA0BE60> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
      0x7fff892b6000 -     0x7fff892d8ff7  libxpc.dylib (140.43) <70BC645B-6952-3264-930C-C835010CCEF9> /usr/lib/system/libxpc.dylib
      0x7fff892e2000 -     0x7fff894ccff7  com.apple.CoreFoundation (6.8 - 744.19) <0F7403CA-2CB8-3D0A-992B-679701DF27CA> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
      0x7fff894cd000 -     0x7fff894edfff  libPng.dylib (850) <203C43BF-FAD3-3CCB-81D5-F2770E36338B> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
      0x7fff89549000 -     0x7fff89646fff  libsqlite3.dylib (138.1) <ADE9CB98-D77D-300C-A32A-556B7440769F> /usr/lib/libsqlite3.dylib
      0x7fff8995d000 -     0x7fff8995eff7  libsystem_sandbox.dylib (220.3) <B739DA63-B675-387A-AD84-412A651143C0> /usr/lib/system/libsystem_sandbox.dylib
      0x7fff8995f000 -     0x7fff899ecff7  com.apple.SearchKit (1.4.0 - 1.4.0) <54A8069C-E497-3B07-BEA7-D3BC9DB5B649> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
      0x7fff89abf000 -     0x7fff89ac6fff  com.apple.NetFS (5.0 - 4.0) <195D8EC9-72BB-3E04-A64D-E1A89B4850C1> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
      0x7fff89b42000 -     0x7fff89c44fff  libJP2.dylib (850) <2E43216C-3A5A-3693-820C-38B360698FA0> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
      0x7fff89d60000 -     0x7fff89f60fff  libicucore.A.dylib (491.11.3) <5783D305-04E8-3D17-94F7-1CEAFA975240> /usr/lib/libicucore.A.dylib
      0x7fff89f61000 -     0x7fff89f8fff7  libsystem_m.dylib (3022.6) <11B6081D-6212-3EAB-9975-BED6234BD6A5> /usr/lib/system/libsystem_m.dylib
      0x7fff89f90000 -     0x7fff8a116fff  libBLAS.dylib (1073.4) <C102C0F6-8CB6-3B49-BA6B-2EB61F0B2784> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
      0x7fff8a21e000 -     0x7fff8a2f8fff  com.apple.backup.framework (1.4.3 - 1.4.3) <6B65C44C-7777-3331-AD9D-438D10AAC777> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup
      0x7fff8a916000 -     0x7fff8a916fff  com.apple.Accelerate.vecLib (3.8 - vecLib 3.8) <B5A18EE8-DF81-38DD-ACAF-7076B2A26225> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
      0x7fff8a917000 -     0x7fff8a966ff7  libFontRegistry.dylib (100) <F7EC0287-58E4-3ABE-A45E-B105A68EA76E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
      0x7fff8a967000 -     0x7fff8a97bfff  com.apple.speech.synthesis.framework (4.1.12 - 4.1.12) <94EDF2AB-809C-3D15-BED5-7AD45B2A7C16> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
      0x7fff8a9a5000 -     0x7fff8aa26fff  com.apple.Metadata (10.7.0 - 707.11) <2DD25313-420D-351A-90F1-300E95C970CA> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
      0x7fff8aafb000 -     0x7fff8ab45ff7  libGLU.dylib (8.9.2) <1B5511FF-1064-3004-A245-972CE5687D37> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
      0x7fff8ab46000 -     0x7fff8ab53fff  libbz2.1.0.dylib (29) <CE9785E8-B535-3504-B392-82F0064D9AF2> /usr/lib/libbz2.1.0.dylib
      0x7fff8ab54000 -     0x7fff8ab73ff7  libresolv.9.dylib (51) <0882DC2D-A892-31FF-AD8C-0BB518C48B23> /usr/lib/libresolv.9.dylib
      0x7fff8ab86000 -     0x7fff8ab87fff  libDiagnosticMessagesClient.dylib (8) <8548E0DC-0D2F-30B6-B045-FE8A038E76D8> /usr/lib/libDiagnosticMessagesClient.dylib
      0x7fff8ab88000 -     0x7fff8abbeff7  libsystem_info.dylib (406.17) <C9BA1024-043C-3BD5-908F-AF709E05DEE4> /usr/lib/system/libsystem_info.dylib
      0x7fff8ac5d000 -     0x7fff8ac5ffff  com.apple.TrustEvaluationAgent (2.0 - 23) <A97D348B-32BF-3E52-8DF2-59BFAD21E1A3> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
      0x7fff8b0d6000 -     0x7fff8b30bff7  com.apple.CoreData (106.1 - 407.7) <24E0A6B4-9ECA-3D12-B26A-72B9DCF09768> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
      0x7fff8b35c000 -     0x7fff8b366fff  com.apple.speech.recognition.framework (4.1.5 - 4.1.5) <5A4B532E-3428-3F0A-8032-B0AFFF72CA3D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
      0x7fff8b370000 -     0x7fff8b3ddff7  com.apple.datadetectorscore (4.1 - 269.3) <5775F0DB-87D6-310D-8B03-E2AD729EFB28> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
      0x7fff8b458000 -     0x7fff8b6fcff7  com.apple.CoreImage (8.4.0 - 1.0.1) <CC6DD22B-FFC6-310B-BE13-2397A02C79EF> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage
      0x7fff8b6fd000 -     0x7fff8b705fff  liblaunch.dylib (442.26.2) <2F71CAF8-6524-329E-AC56-C506658B4C0C> /usr/lib/system/liblaunch.dylib
      0x7fff8b706000 -     0x7fff8b734fff  com.apple.CoreServicesInternal (154.3 - 154.3) <F4E118E4-E327-3314-83D7-EA20B1717ED0> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal
      0x7fff8b735000 -     0x7fff8b75fff7  com.apple.CoreVideo (1.8 - 99.4) <E5082966-6D81-3973-A05A-38AA5B85F886> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
      0x7fff8b7bc000 -     0x7fff8bad3ff7  com.apple.CoreServices.CarbonCore (1037.6 - 1037.6) <1E567A52-677F-3168-979F-5FBB0818D52B> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
      0x7fff8beb0000 -     0x7fff8c2a7fff  libLAPACK.dylib (1073.4) <D632EC8B-2BA0-3853-800A-20DA00A1091C> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
      0x7fff8c2cb000 -     0x7fff8c2e8ff7  com.apple.openscripting (1.3.6 - 148.3) <C008F56A-1E01-3D4C-A9AF-97799D0FAE69> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
      0x7fff8c2e9000 -     0x7fff8c43bfff  com.apple.audio.toolbox.AudioToolbox (1.9 - 1.9) <62770C0F-5600-3EF9-A893-8A234663FFF5> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
      0x7fff8c43c000 -     0x7fff8c4bcff7  com.apple.ApplicationServices.ATS (332 - 341.1) <AFDC05E6-F842-33D9-9379-81DF26E510CA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
      0x7fff8c4bd000 -     0x7fff8c53bff7  com.apple.securityfoundation (6.0 - 55115.4) <137E156C-B29C-3B84-95B3-669BC7C1BA7A> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
      0x7fff8c53c000 -     0x7fff8c5f9ff7  com.apple.ColorSync (4.8.0 - 4.8.0) <73BE495D-8985-3B88-A7D0-23DF0CB50304> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
      0x7fff8c5fa000 -     0x7fff8c5feff7  com.apple.TCC (1.0 - 1) <76A86876-2280-3849-8478-450E1A8C0E01> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
      0x7fff8c602000 -     0x7fff8c64eff7  libauto.dylib (185.4) <AD5A4CE7-CB53-313C-9FAE-673303CC2D35> /usr/lib/libauto.dylib
      0x7fff8c64f000 -     0x7fff8c68eff7  com.apple.QD (3.42.1 - 285.1) <77A20C25-EBB5-341C-A05C-5D458B97AD5C> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
      0x7fff8c68f000 -     0x7fff8c69cff7  com.apple.NetAuth (4.0 - 4.0) <A4A21A2F-B26A-3DC9-95E4-DAFA43A4A2C3> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
      0x7fff8c6ed000 -     0x7fff8d31afff  com.apple.AppKit (6.8 - 1187.39) <199962F0-B06B-3666-8FD5-5C90374BA16A> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
      0x7fff8d6d6000 -     0x7fff8d6fefff  libJPEG.dylib (850) <DC750E1E-BD07-339B-A4A6-D86BFE969F68> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
      0x7fff8d6ff000 -     0x7fff8d739ff7  com.apple.GSS (3.0 - 2.0) <970CAE00-1437-3F4E-B677-0FDB3714C08C> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
      0x7fff8d813000 -     0x7fff8da80ff7  com.apple.RawCamera.bundle (4.07 - 696) <CCB97D78-309C-3CD9-B499-81192069A333> /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera
      0x7fff8da81000 -     0x7fff8dad0ff7  libcorecrypto.dylib (106.2) <CE0C29A3-C420-339B-ADAA-52F4683233CC> /usr/lib/system/libcorecrypto.dylib
      0x7fff8dad1000 -     0x7fff8dadaff7  com.apple.CommerceCore (1.0 - 26.1) <40A129A8-4E5D-3C7A-B299-8CB203C4C65D> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore
      0x7fff8dd3f000 -     0x7fff8dd54ff7  libdispatch.dylib (228.23) <D26996BF-FC57-39EB-8829-F63585561E09> /usr/lib/system/libdispatch.dylib
      0x7fff8dd55000 -     0x7fff8dd58fff  libRadiance.dylib (850) <62E3F7FB-03E3-3937-A857-AF57A75EAF09> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
      0x7fff8dd8c000 -     0x7fff8dd8dff7  libdnsinfo.dylib (453.19) <14202FFB-C3CA-3FCC-94B0-14611BF8692D> /usr/lib/system/libdnsinfo.dylib
      0x7fff8e042000 -     0x7fff8e05dff7  libsystem_kernel.dylib (2050.24.15) <A9F97289-7985-31D6-AF89-151830684461> /usr/lib/system/libsystem_kernel.dylib

  External Modification Summary:
    Calls made by other processes targeting this process:
      task_for_pid: 2
      thread_create: 0
      thread_set_state: 0
    Calls made by this process:
      task_for_pid: 0
      thread_create: 0
      thread_set_state: 0
    Calls made by all processes on this machine:
      task_for_pid: 1130
      thread_create: 1
      thread_set_state: 0

  VM Region Summary:
  ReadOnly portion of Libraries: Total=150.0M resident=109.2M(73%) swapped_out_or_unallocated=40.8M(27%)
  Writable regions: Total=101.9M written=10.4M(10%) resident=65.3M(64%) swapped_out=0K(0%) unallocated=36.6M(36%)
   
  REGION TYPE                      VIRTUAL
  ===========                      =======
  CG backing stores                  21.9M
  CG image                           4176K
  CG raster data                       96K
  CG shared images                    192K
  CoreServices                       1628K
  MALLOC                             49.2M
  MALLOC guard page                    48K
  Memory tag=242                       12K
  Memory tag=251                        8K
  STACK GUARD                        56.0M
  Stack                              9820K
  VM_ALLOCATE                        16.4M
  __DATA                             11.1M
  __IMAGE                             528K
  __LINKEDIT                         52.7M
  __TEXT                             97.3M
  __UNICODE                           544K
  mapped file                        59.2M
  shared memory                       308K
  ===========                      =======
  TOTAL                             380.7M

  Model: MacBookPro10,2, BootROM MBP102.0106.B03, 2 processors, Intel Core i5, 2.5 GHz, 8 GB, SMC 2.6f57
  Graphics: Intel HD Graphics 4000, Intel HD Graphics 4000, Built-In, 768 MB
  Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D5434314753364D465238432D50422020
  Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x484D5434314753364D465238432D50422020
  AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x10F), Broadcom BCM43xx 1.0 (5.106.98.100.17)
  Bluetooth: Version 4.1.4f2 12041, 2 service, 11 devices, 1 incoming serial ports
  Network Service: Wi-Fi, AirPort, en0
  Serial ATA Device: APPLE SSD SM128E, 121,33 GB
  USB Device: Gaming Mouse G400, 0x046d  (Logitech Inc.), 0xc245, 0x14300000 / 1
  USB Device: hub_device, 0x8087  (Intel Corporation), 0x0024, 0x1d100000 / 2
  USB Device: hub_device, 0x0424  (SMSC), 0x2512, 0x1d180000 / 3
  USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x025a, 0x1d182000 / 5
  USB Device: BRCM20702 Hub, 0x0a5c  (Broadcom Corp.), 0x4500, 0x1d181000 / 4
  USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x828c, 0x1d181300 / 8
  USB Device: hub_device, 0x8087  (Intel Corporation), 0x0024, 0x1a100000 / 2
  USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8510, 0x1a110000 / 3


tkt_uuid: 881414ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 9 Immediate
foundin: obsolete: 8.5a0
resolution: Duplicate
title: 1 fatal error plus 7 other errors in tk test suite
comment:
  Platform: SPARC Solaris 8, running Sun's GNOME 2 desktop.

  Tcl/Tk from 20040120 cvs.

  Tcl configured with:
  ./configure --prefix=/volws/lwv26/ldatae
  --enable-shared --enable-symbols --enable-threads

  and Tk configured with
  ./configure --prefix=/volws/lwv26/ldatae
  --enable-shared --enable-symbols

  When I run make test I get these unexpected failures:

  unixWm.test

  ==== 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+0+40
  ---- Result should have been (exact matching):
  100x150+0+0
  ==== unixWm-4.3 FAILED

  ==== unixWm-50.1 Tk_CoordsToWindow procedure, finding a
  toplevel, x-coords FAILE
  D
  ==== 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 [e
  xpr $x - 1] [expr $y + 250]]  [winfo containing $x
  [expr $y + 250]]  [winfo cont
  aining [expr $x + 99] [expr $y + 250]]  [winfo
  containing [expr $x + 100] [expr 
  $y + 250]]  [winfo containing [expr $x + 199] [expr $y
  + 250]]  [winfo containin
  g [expr $x + 200] [expr $y + 250]]  [winfo containing
  [expr $x + 220] [expr $y +
   250]]

  ---- Result was:
  {} {} .t .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]  [winfo 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


  and then, when the window.test occurs, I see the Visual
  test window, windows t, t2, t1 and script.  But the
  test never finishes!
  When I kill the hanging process, I get the error:
  window.test

  ==== window-2.9 Tk_DestroyWindow, Destroy bindings
          evaluated after exit FAILED
  ==== Contents of test case:

      set code [loadTkCommand]
      append code {
          toplevel .t1
          toplevel .t2
          update
          bind .t2 <Destroy> {puts "Destroy .t2" ; exit 1}
          bind .t1 <Destroy> {puts "Destroy .t1" ; exit 0}
          destroy .t2
      }
      set script [makeFile $code script]
      if {[catch {exec [interpreter] $script -geometry
  10x10+0+0} msg]} {
          set error 1
      } else {
          set error 0
      }
      removeFile script
      list $error $msg

  ---- Result was:
  1 {Destroy .t2
  Destroy .t1
  child killed: software termination signal}
  ---- Result should have been (exact matching):
  0 {Destroy .t2
  Destroy .t1}
  ==== window-2.9 FAILED


tkt_uuid: 886240ffffffffffffffffffffffffffffffffff
type: Support
status: Closed
subsystem: None
priority: 8
foundin: None
title: TIP 168: Cubic Bezier curves on the canvas
comment:
  This file contains changes that implement a "raw" 
  -smooth method (as described in TIP 168) for canvas
  items. It also does some cleanup of terminology in
  comments to specific functions.

  Affected files are tkTrig.c, tkCanvUtil.c,
  and tkInt.decls.


tkt_uuid: 886915ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: Fixed
title: Toplevel problems under Windows
comment:
  I have found two problems with bgerror under windows,
  with wish8.4.5. The problem occurs with bgerror, but I
  think these are more related to windows toplevel.
  The following script:

     after idle error

  * started in a file, nothings happen: . is not mapped,
  neither the bgerror dialog.

  * in a wish console, the bgerror dialog "flash" before
  being displayed. This looks like an old bug (fixed in
  version 1.12 of win/tkWinWm.c ?)


tkt_uuid: 891141ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 6
foundin: obsolete: 8.4.13
resolution: Fixed
title: Entry/Leave events cause variable writes
comment:
  I've report a similiar problem, which was LINUX specific 
  and eventually blamed on the compiler. This time, it 
  occurs on multiple platforms.

  If a trace is set up to watch writes to a variable, and 
  the variable is also used as the -variable parameter to a 
  scale widget, the variable gets written, even though it's 
  contents remains unchanged, during Leave and Enter 
  events (NOTE: Depends on value, for example 3.5 is OK, 
  but 3.4 causes a variable write on all Leave/Enters)

  I've attached an example.


tkt_uuid: 892194ffffffffffffffffffffffffffffffffff
type: Support
status: Closed
subsystem: None
priority: 6
foundin: None
title: TIP #222 - Windows toplevel transparency (-alpha) option
comment:
  The attached patch is a demo for Win2K/XP alpha
  transparency for entire toplevels.  While cool looking
  ... it's all relatively useless outside of demos and
  splash screens.  I attach it here for reference.  Made
  against win/tkWinWm.c of 8.5a0.


tkt_uuid: 892880ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: None
resolution: Invalid
title: Accelerate WINDOWS wish startup
comment:
  Accelerate WINDOWS startup if 'consoleRequired' within 
  win/winMain.c is set to FALSE for argc > 1. Otherwise 
  the time consuming initialization of external packages is 
  done twice ! (UNIX ok)


tkt_uuid: 894550ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 31. Cursor Names
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Fixed
title: TkAqua:Empty cursor ignored in canvas and text widget (OS X)
comment:
  The empty cursor name {} is ignored on OS X when configuring a 
  canvas or text widget from an event binding (this may happen with 
  other widgets, and in other circumstances, but I haven't been able 
  to verify this). For instance, both these scripts exhibit the bug:

  pack [text .t]
  .t tag configure link -foreground red
  .t tag bind link <Enter> [list .t configure cursor hand]
  .t tag bind link <Leave> [list .t configure -cursor {}]
  .t insert end "Normal text\n"
  .t insert end "This is a link\n" link
  .t insert end "More normal text\n"

  and (for the canvas):

  pack [canvas .c]
  .c create rect 50 50 100 100 -fill red -tags link
  .c bind link <Enter> [list .c configure -cursor hand]
  .c bind link <Leave> [list .c configure -cursor {}]

  In both of these scripts, the cursor remains the "hand" cursor 
  when the mouse leaves the link area. I believe the {} cursor name 
  should restore the cursor to its default state, but I haven't found 
  where this is stated in the docs (nothing in the Tk_GetCursor 
  manpage seems to mention the {} cursor). However, several 
  applications use this empty cursor name to restore the cursor (for 
  instance TkChat relies on this behaviour).

  The <Leave> event definitely fires (changing the binding to just do 
  a puts verifies this), so the bug must be in the configure code. 
  However, the following script works ok:

  pack [canvas .c]
  .c configure -cursor hand
  .c configure -cursor {}

  (the cursor returns the the default arrow). This script doesn't:

  pack [canvas .c]
  .c configure -cursor hand
  after 5000 [list .c configure -cursor {}]

  So, it appears to be only configuring the cursor to {} in an event 
  which fails (the same after code, with -cursor ibeam works).


tkt_uuid: 894561ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: None
title: Buttons don't appear in dialogs
comment:
  Another TkAqua bug, noticed while using TkChat. On most of the 
  dialog boxes which are displayed, any buttons which are added do 
  not display until some action is taking. For instance, in the dialog 
  which pops up to ask how much history to load, the radiobuttons 
  for the days appear, but the "OK" button does not. Clicking on one 
  of the radio buttons makes the OK button appear. An even worse 
  example is the About box, which should have a large "Dismiss" 
  button across the bottom, but this doesn't appear. As there are no 
  other controls on this dialog, the only way to get the button to 
  appear is to click in the area where it should be. It then appears, 
  but closes the window.

  I have not currently been able to come up with a minimal script 
  which reproduces this behaviour, or indeed, reproduce it at all 
  outside of TkChat.


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: 895638ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: Duplicate
title: Bold fonts displayed incorrectly in text widget
comment:
  On Windows/NT OS's , the following re-creates the 
  problem

  #####
  pack [text .a -font {{MS sans serif} 8 bold}]
  .a insert 0.0 {Move the cursor through this text to see 
  the problem}
  #####

  Whilst moving cursor through the text, the text 
  spacing 'jiggles' about. 

  Problem varies between font family used. Some families 
  do not exhibit this problem.


tkt_uuid: 895899ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: Invalid
title: Search order for the tclConfig.sh
comment:
  I'm having troubles when installing Tcl/Tk on Solaris into
  non-standard location. configure/build of the Tcl went
  fine but configure for the Tk fails whith
   "Use --with-tcl= option ...". 
  The problem is that I have an old version installed in 
  /usr/local. Last time I checked (8.3.*) Tk's configure 
  used to check --prefix location first.

  It is not really a bug, but the old behaviour was much
  more convenient IMHO.


tkt_uuid: 899010ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 9 Immediate
foundin: obsolete: 8.4.6
resolution: Fixed
title: imgPhoto-16.1 test error
comment:
  On Solaris 9, CDE 1.5:

  ==== 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
      set photo [image create photo]
      $i put red -to 0 0 1000 1000
      $i copy $i -from 0 0 1000 1000 -to 500 0
      image delete $i

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: can't read "i": no such variable
      while executing
  "$i put red -to 0 0 1000 1000"
      ("uplevel" body line 4)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== imgPhoto-16.1 FAILED

  Really should fix before 8.4.6 is released.


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: 8eb56719cff9c2e5bb76230017fd65c649526bcf
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
severity: Important
foundin: 8.5.14
private_contact: 5312fcfb57a92ddd64553c14c04a390a9032b63f
resolution: None
title: macosx Tk compile errors/warnings due to bad merge
comment:
  Current versions of two Aqua modules, <b>macosx/tkMacOSXClipboard.c</b> and <b>macosx/tkMacOSXDraw.c</b>, get compile warnings when compiled with <b>gcc</b> and compile errors when attempting to compile with Apple <b>clang</b>.  Both errors are due to misplaced <b>return Success</b> statements.  From comparing the 8.5.14 and 8.5.15rc1 sources with the 8.6.0 and 8.6.1.rc0 sources, my guess is that the problems are due to an incorrect merge at some point of the Aqua code from 8.6 into 8.5, since the 8.6 code is correct.

  Here are the results of compiling 8.5.15rc1 on OS X 10.8.5 with the current Xcode 4.6.3 command line tools installed.  (8.5.14 results are similar.)

  <verbatim>
  $ gcc --version
  i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
  $ cd tk8.5.15/unix && ./configure --prefix=/tmp/a/root --enable-shared --enable-threads --enable-aqua && make
  [...]
  /tmp/a/tk8.5.15/unix/../macosx/tkMacOSXClipboard.c: In function ‘XSetSelectionOwner’:
  /tmp/a/tk8.5.15/unix/../macosx/tkMacOSXClipboard.c:171: warning: no return statement in function returning non-void
  /tmp/a/tk8.5.15/unix/../macosx/tkMacOSXClipboard.c: In function ‘TkMacOSXSelDeadWindow’:
  /tmp/a/tk8.5.15/unix/../macosx/tkMacOSXClipboard.c:197: warning: ‘return’ with a value, in function returning void
  [...]
  /tmp/a/tk8.5.15/unix/../macosx/tkMacOSXDraw.c: In function ‘DrawCGImage’:
  /tmp/a/tk8.5.15/unix/../macosx/tkMacOSXDraw.c:747: warning: ‘return’ with a value, in function returning void
  /tmp/a/tk8.5.15/unix/../macosx/tkMacOSXDraw.c: In function ‘TkPutImage’:
  /tmp/a/tk8.5.15/unix/../macosx/tkMacOSXDraw.c:350: warning: control reaches end of non-void function
  /tmp/a/tk8.5.15/unix/../macosx/tkMacOSXClipboard.c:171:1: warning: control reaches end of
        non-void function [-Wreturn-type]


  $ cc --version
  Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
  Target: x86_64-apple-darwin12.5.0
  Thread model: posix
  $ cd tk8.5.15/unix && ./configure --prefix=/tmp/a/root --enable-shared --enable-threads --enable-aqua CC=cc && make
  [...]
  /tmp/a/tk8.5.15/unix/../macosx/tkMacOSXClipboard.c:171:1: warning: control reaches end of
        non-void function [-Wreturn-type]
  }
  ^
  /tmp/a/tk8.5.15/unix/../macosx/tkMacOSXClipboard.c:197:5: error: void function
        'TkMacOSXSelDeadWindow' should not return a value [-Wreturn-type]
      return Success;
      ^      ~~~~~~~
  1 warning and 1 error generated.
  [...]
  tmp/a/tk8.5.15/unix/../macosx/tkMacOSXDraw.c:350:1: warning: control may reach end of
        non-void function [-Wreturn-type]
  }
  ^
  /tmp/a/tk8.5.15/unix/../macosx/tkMacOSXDraw.c:747:5: error: void function 'DrawCGImage'
        should not return a value [-Wreturn-type]
      return Success;
      ^      ~~~~~~~
  1 warning and 1 error generated.
  </verbatim>
  Note that, with the next release of Apple's Xcode development tools, expected with the upcoming OS X 10.9 (Mavericks) release, Apple will no longer ship any gcc-based compilers, just clang, so it is important that Tk builds correctly with clang.

  The attached patch fixes the problems.


tkt_uuid: 900489ffffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: None
title: canvas, move item, pixel dust
comment:
  (this was posted in c.l.t on 2004-02-19)

  Hi Folks,

  Using the Tk-script below, if you Left-Button-Click on
  the yellow disc (then keep pressing B1), and move it,
  some pixel dust is left when you move it from
  right->left of the canvas (left to right is fine). To
  better see them, note that the slower you move the more
  dust you leave.
  Now if I tweak 'radius' from 25 to 26, it does the
  same, bit if it is set to 24, it leaves the place clean!

  Observed on:
    Tk8.4.5, WinXPhome  -> dust
    nVIDIA GeForce G05200, 64MB, 24bit
    UXGA (1600x1200), Notebook (laptop)
    P4ht Dell Inspiron 5150

    Tk8.4.4, Win2000Pro -> dust
    ATI 3D RAGE Pro, AGP2X, 4MB, 16bit
    1152x864, Desktop, PIII  

  (I don't have the driver's or other info handy right
  now but see Kevin's post added below).

  (if you minimize/maximize or raise/lower it cleans it up.)

  But:
    Tk8.4.4, SunUltra5-Gnome  -> fine!

  Here are a couple of screenshots:
   http://dire.straits.free.fr/TCLTK/bug1.jpg
   http://dire.straits.free.fr/TCLTK/bug0.jpg

  Anything I'm doing wrong?, bug?, etc.?

  Thanks,

  --Fred
  (fphenix at hotmail)


  #!/bin/sh
  # Fred \
  exec wish "$9" ${1+"$@"}

  if {[string equal $tcl_platform(platform) "windows"]} {
    console show
  }
  puts $tk_patchLevel

  proc moveit {object x y} {
    set radius 25 ;# 25,26=dust, 24=clean
    .screen coords $object [expr $x-$radius] [expr
  $y-$radius] \
                           [expr $x+$radius] [expr
  $y+$radius]
  }

  pack [canvas .screen -width 200m -height 400 -bg black \
                        -borderwidth 1]
  set myov [.screen create oval 500 50 550 100 -outline
  orange \
                                  -width 4 -fill yellow]
  .screen bind $myov <B1-Motion> {moveit $myov %x %y}

  ;#end-of-script


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

  Kevin Kenny replied:

  You're not doing anything wrong, and I get the same results
  on my Win2k box.

  These things are often sensitively dependent on the video
  configuration as well (that is, Tk sometimes tickles bugs
  in the video drivers...), so for what it's worth:

  Name            Radeon Mobility
  PNP Device ID        \
     
  PCI\VEN_1002&DEV_4C59&SUBSYS_00E31028&REV_00\4&45A7597&0&0008
  Adapter Type        \
      ATI Mobility M6 (LY), ATI Technologies Inc. compatible
  Adapter Description    Radeon Mobility
  Adapter RAM        16.00 MB (16,777,216 bytes)
  Installed Drivers    ati2dvag.dll
  Driver Version        5.13.01.3293
  INF File        oem1.inf (ati2mtag_M6 section)
  Color Planes        1
  Color Table Entries    4294967296
  Resolution        1600 x 1200 x 85 hertz
  Bits/Pixel        32

  Log it at SourceForge
  (http://www.sourceforge.net/projects/tktoolkit/),
  please?
  -- 
  73 de ke9tv/2, Kevin 


tkt_uuid: 901880ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: Invalid
title: "Motion" binding fails during startup
comment:
  This  code is called (within panedwindow.tcl) due to a
  binding of a panedwindow widget as my application is
  starting up (but prior to any user input):

  proc ::tk::panedwindow::Motion {w x y} {
  set id [$w identify $x $y]
  ....

  The trouble appears to be that while the application is
  starting up (widgets are being created), there is a
  race (within the various widgets, as I don't see how I
  can influence this...) between when this binding is
  assigned and when various resources are actually
  created (to the point that they support an "identify"
  call).

  I randomly get this error:
  Error: bad option "identify": should be one of...
  ....

  It happens 1 out of of 3 times I start up the
  application - the other 2 of 3 times everything works...

  It never occurs again after the application is running,
  presumably because now the resources is fully
  initialized and responds as expected to an "identify"
  request.

  The flow of my application is:

  1. create toplevel
  2. create panedwdiget
  3. create child(ren) of panedwidget within "childsite(s)"
  4. place, place, place
  5. enter event loop

  I have had no luck creating a smaller application to
  demonstrate this as it appears that the shear size of
  my application is what increases the likelyhood that
  this race will occur.  This root cause (failure to
  answer the "identify" request) might be a bigger
  problem, but it seems that this library code
  could/should trap this case as a matter of  cleanliness
  (other calls in this file do similar things that
  ideally would have similar traps).

  As an additionaly note, running with a slower link to
  the Xserver (i.e remote display over wireless ethernet)
  reduces the occurance of this error to near zero -
  further demonstrating that this is a race of some sort...

  System info:
  Using VTCL as an IDE, but hand editing code after
  inital widget creation/placement
  RH 7/8/9 (same result on all)
  Window managers (same result on all): 
  a. KDE
  b. remote display to NT + Xwin32 client
  c. gnome 

  Using Tcl/tk ("wish") with itcl/itk/BLT/iwidgets all
  latest stable versions as of ~2/12/2004

  The easy solution seems simple and harmless enough and
  perhaps should be applied to most of the bound
  functions in this file (panedwindow.tcl):
  --- panedwindow.tcl     Fri Feb 20 17:08:23 2004
  +++ panedwindow.tcl~    Mon Feb  9 13:14:48 2004
  @@ -108,12 +108,7 @@
   #
   proc ::tk::panedwindow::Motion {w x y} {
       variable ::tk::Priv
  -    # this resource may not yet be fully initialized,
  if so return without
  -    # doing anything...
  -    if {[catch {set id [$w identify $x $y]}]} {
  -       return
  -    }
  -
  +    set id [$w identify $x $y]
       if {([llength $id] == 2) && \
              (!$::tk_strictMotif || [string equal
  [lindex $id 1] "handle"])} {
          if { ![info exists Priv($w,panecursor)] } {


tkt_uuid: 903415ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Invalid
title: Build warnings under mingw
comment:
  Building with mingw gcc under win2k produces some warnings:

  gcc.exe (GCC) 3.2 (mingw special 20020817-1)

  Michael


tkt_uuid: 903427ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Wont Fix
title: test failures with Tk from cvs on german w2k
comment:
  Attached is the log from running the test suite, i
  experience a hang in winDialog.test

  Looks like the test suit does not work well with a
  localized windows.


tkt_uuid: 904371ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 8
foundin: None
resolution: Fixed
title: Unicode support inconsistency between menu titles and items
comment:
  The following script:

  ---------------------------------------
  menu .mb
  . configure -menu .mb

  menu .mb.m1
  set s1 "\u3072\u3089\u304C\u306A"
  .mb add cascade -label $s1 -menu .mb.m1
  .mb.m1 add command -label $s1

  menu .mb.m2
  set s3 "G\u00E9n\u00E9ration"
  .mb add cascade -label $s3 -menu .mb.m2
  .mb.m2 add command -label $s3

  wm title . "$s1 - $s3"
  ---------------------------------------

  does not work as expected on a french version of
  Windows 2k:
  - the accented characters in the second menu show up
  correctly in menu titles and items
  - if a japanese font is not installed, the characters
  in the first menu show up as '?' in titles and as
  squares in items
  - if a japanese font is installed, the characters are
  correctly displayed in items, but still show up as '?'
  in the first menu title

  This has been tested with tcl/tk 8.3.4 and 8.4.1


tkt_uuid: 905830ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 8
foundin: obsolete: 8.4.12
resolution: Fixed
title: Fix needed for Solaris & SCIM IME support
comment:
  To date, developers here have been unable to get tcl/tk
  8 to interact with the japenese kanji input method
  application kinput2 while using SPARC Solaris 8.

  However, one of our developers spent some time and
  worked out the changes necessary to get this to work.

  Here is what the developer reported back to me,
  regarding the slight change needed so that things work
  right on Solaris:

  ./tk8.4.5/generic/tkEvent.c
  880a881
  >           long im_event_mask;
  933a935,938
  >           XGetICValues(winPtr->inputContext,
  XNFilterEvents, &im_event_mask, N
  ULL);
  >           winPtr->atts.event_mask |= im_event_mask;
  >           XSelectInput(winPtr->display,
  winPtr->window, winPtr->atts.event_mas
  k);
  >           XSetICFocus(winPtr->inputContext);

  The contractor went on to say:

     Basically, the window wasn't requesting input method
  events before trying to  filter them with XFilterEvent.
   There is nothing in the code I added that is Solaris
  specific.  I don't know why Japanese input behaves
  differently than on other Unix versions.


tkt_uuid: 907323ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: None
title: "Modernise" keysyms (PgUp and PgDn)
comment:
  I noticed that some common keys found on most modern
  keyboards are not in the present list of keysyms or
  only under an obbscure synonym.

  Most noticeably these are: PgUp and PgDn.
  They are present under the "old" names Prior and Next,
  which to the average programmer used to PC keyboards
  will not be obvious.


tkt_uuid: 910127ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 8
foundin: obsolete: 8.4.5
resolution: Duplicate
title: certain characters cannot be inserted into an entry
comment:
  Dear Team,

  The odoubleacute and udoubleacute symbols cannot be 
  inserted into, say, a text or an entry. These symbols 
  can be generated with any standard distribution using 
  "setxkbmap hu", by pressing '[' or '\'.

  Here is a testprogram:

  wish8.4 [~]entry .e
  .e
  wish8.4 [~]pack .e
  wish8.4 [~]bind .e <Key> {puts "%K, %A, %N"}

  After pressing these keys, the output is:

  odoubleacute, {}, 501
  udoubleacute, {}, 507
  Shift_L, {}, 65505
  Odoubleacute, {}, 469
  Udoubleacute, {}, 475

  I tested it with a Mandrake 9.2 install, and with a 
  cygwin XFree86 server.

  Is it the problem of tk, or the problem of X?

  (There are other hungarian keyboard layouts, which use 
  latin2-encoding instead of unicode, and there these two 
  keys generate otilde and uumlaut keysyms, which are 
  happily accepted by tk, but not, for example, by 
  StarOffice. :((  )


tkt_uuid: 911951ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.5a1
resolution: None
title: Menu geometry info wrong if cascaded
comment:
  If you post a menu directly with the post widget
  command, or associate it with a menubutton and click on
  that to post it, you can get info about its position
  using the wm or winfo commands. However if you display
  it by clicking on a cascade entry in another menu, this
  information is wrong. The geometry comes up as 0x0+1+1
  if it is displayed for the first time, or whatever it
  was when it was last invoked directly or from a menubutton.

  Tested on TclTk 8.4.2 with red hat linux 7.3
  and 8.4.3, 8.4.6, and 8.5a1 with red hat linux 9


tkt_uuid: 912571ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 9 Immediate
foundin: obsolete: 8.4.13
resolution: Fixed
title: wish crashing during exit when stdin is closed.
comment:
  Steps to reproduce:

  1. On Windows, run wish (either 8.4 or 8.5 will do).
  2. In the console window, evaluate "close stdin".
  3. Close the Tk app window.
  4. Crash.

  DeleteChannelTable(void * 0x01026480, Tcl_Interp * 
  0x00ffb838) line 600 + 3 bytes
  DeleteInterpProc(Tcl_Interp * 0x00ffb838) line 1055 + 
  18 bytes
  Tcl_EventuallyFree(void * 0x00ffb838, void (char *)* 
  0x10012771 DeleteInterpProc(Tcl_Interp *)) line 311 + 9 
  bytes
  Tcl_DeleteInterp(Tcl_Interp * 0x00ffb838) line 943 + 14 
  bytes
  ConsoleDeleteProc(void * 0x00f3ef38) line 699 + 19 
  bytes
  Tcl_DeleteCommandFromToken(Tcl_Interp * 
  0x008cade8, Tcl_Command_ * 0x00f224e0) line 2552 + 
  15 bytes
  TclTeardownNamespace(Namespace * 0x008ccde8) line 
  956 + 13 bytes
  DeleteInterpProc(Tcl_Interp * 0x008cade8) line 1005 + 
  12 bytes
  Tcl_EventuallyFree(void * 0x008cade8, void (char *)* 
  0x10012771 DeleteInterpProc(Tcl_Interp *)) line 311 + 9 
  bytes
  Tcl_DeleteInterp(Tcl_Interp * 0x008cade8) line 943 + 14 
  bytes
  Tk_MainEx(int 1, char * * 0x008d0060, int (Tcl_Interp *)
  * 0x004010f3 Tcl_AppInit(Tcl_Interp *), Tcl_Interp * 
  0x008cade8) line 303 + 18 bytes
  WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 
  0x00000000, char * 0x00133750, int 1) line 129 + 37 
  bytes
  WinMainCRTStartup() line 330 + 54 bytes
  KERNEL32! GetProcessPriorityBoost + 279 bytes


tkt_uuid: 915330ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 7 High
foundin: obsolete: 8.5a1
resolution: Fixed
title: Crash w/checkbutton when colors stressed
comment:
  (unix only)

  When using a display where the colors are stressed and
  exhausted, a crash will occur when rendering a
  checkbutton or radio button.

  The attatched patch will fix the problem.

  -Brian


tkt_uuid: 915350ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 8
foundin: obsolete: 8.4.6
resolution: Fixed
title: Tk sets min, max size in WM_HINTS when it shouldn't
comment:
  (See also: http://bugs.kde.org/show_bug.cgi?id=67577)

  Problem: Tk toplevels always set the min_width,
  min_height, max_width, and max_height fields in the
  WM_NORMAL_HINTS property, even when the user has not
  called [wm minsize] or [wm maxsize].   

  The default minimum size is 1x1 (which is redundant),
  and the default maximum is taken from the size of the
  screen (which is not even correct in the context of
  multi-head displays). 

  This causes recent versions of KWM (and possibly other
  WMs) to disable maximization.  In any event, Tk
  shouldn't specify these fields unless explicitly
  instructed to.


tkt_uuid: 917195ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 4
foundin: None
resolution: None
title: TkMacOSXXPutPixel() / tkdvi
comment:
  Submitted by Matthieu Quignard (quignard@loria.fr) as 
  requested by Daniel A. Steffen (das)

  Context : building tkdvi (0.4) by Anselm Lingnau, on MacOS 
  X (10.2.8) with Tcl/Tk Aqua (8.4.6).

  Configure :
  set tcldir=/Library/Frameworks/Tcl.framework/Versions/
  Current
  set tclincdir=$tcldir/Headers
  set tkdir=/Library/Frameworks/Tk.framework/Versions/
  Current
  set tkincdir=$tkdir/Headers
  set kpathdir=/sw/lib
  set kpathincdir=/sw/include/kpathsea
  (kpathsea got from fink tetex-dev)

  ./configure --with-tcl=$tcldir
  --with-tclinclude=$tclincdir --
  with-tk=$tkdir --with-tkinclude=$tkincdir --with-
  kpathsea=$kpathdir 
  --with-kpathseainclude=$kpathincdir --enable-debug --
  disable-threads

  Fix the Makefile in ./dvi :
  * Add -DHAVE_PROTOTYPES=1 to compile with gcc 3.3 and 
  remove -DUSE_STUBS_TK=1 -DUSE_STUBS_TCL=1
  * link with -L/Library/Frameworks/Tk.framework/Versions/
  8.4 -L/Library/Frameworks/Tcl.framework/Versions/8.4 -
  framework Tcl -framework Tk -lpthread -framework 
  CoreFoundation

  Compiling and linking are succesfull.

  Testing (tkdvi testdvi/mini) leads to Segmentation fault.

  Here is the crash report :
  Date/Time:  2004-03-16 10:12:24 +0100
  OS Version: 10.2.8 (Build 6R73)
  Host:       vercors.loria.fr

  Command:    Wish Shell
  PID:        2138

  Exception:  EXC_BAD_ACCESS (0x0001)
  Codes:      KERN_INVALID_ADDRESS (0x0001) at 0xffff0000

  Thread 0 Crashed:
   #0   0x91ad9754 in SetCPixel
   #1   0x0b094518 in TkMacOSXXPutPixel
   #2   0x01338fc0 in GlyphToImageShrink
   #3   0x013391c4 in RenderGlyph
   #4   0x013326fc in Dvi_DoInterpret
   #5   0x01339a58 in DviImgDisplay
   #6   0x0b03b044 in Tk_RedrawImage
   #7   0x0b013bac in DisplayImage
   #8   0x0b00ef5c in DisplayCanvas
   #9   0x0a066f74 in TclServiceIdle
   #10  0x0a056910 in Tcl_DoOneEvent
   #11  0x0b033628 in MapFrame
   #12  0x0a066f74 in TclServiceIdle
   #13  0x0a056910 in Tcl_DoOneEvent
   #14  0x0b02d2f8 in Tk_MainLoop
   #15  0x0b04ab50 in Tk_MainEx
   #16  0x00010180 in 0x10180
   #17  0x0000ffa8 in 0xffa8
   #18  0x0000fe28 in 0xfe28

  Thread 1:
   #0   0x9002568c in select
   #1   0x0b08a658 in NotifierThreadProc
   #2   0x90020c28 in _pthread_body

  PPC Thread State:
    srr0: 0x91ad9754 srr1: 0x0200f030                vrsave: 
  0x00000000
     xer: 0x20000000   lr: 0x91ad9740  ctr: 0x902216d0   mq: 
  0x00000000
      r0: 0x91ad9740   r1: 0xbfffef80   r2: 0x01436788   r3: 
  0x00000000
      r4: 0x00000000   r5: 0xbffff048   r6: 0x69012501   r7: 
  0x0133c9d8
      r8: 0x0128623c   r9: 0xffff0000  r10: 0x0133c8d8  r11: 
  0xa1a50cd0
     r12: 0x902216d0  r13: 0x00000000  r14: 0x00000000  
  r15: 0x00000000
     r16: 0xbffff184  r17: 0xbffff180  r18: 0x0140ce08  r19: 
  0x00000005
     r20: 0x00000000  r21: 0x01286234  r22: 0x00000000  
  r23: 0x00000008
     r24: 0x00000039  r25: 0xbffff048  r26: 0x00000000  r27: 
  0x00000000
     r28: 0x69012501  r29: 0x00000000  r30: 0x0129be08  
  r31: 0x01338d3c


tkt_uuid: 917433ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 30. Color Names
priority: 9 Immediate
foundin: obsolete: 8.4.6
resolution: Fixed
title: Application initialization failed: unknown color name
comment:
  Whne trying to run amsn on linux in the console i get
  thiss error that i think has with wish to do?

  Application initialization failed: unknown color name
  "Black" 


tkt_uuid: 917557ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: None
resolution: Fixed
title: Hide Wish Shell with
comment:
  If we are in Wish Shell and try to hide with "Command-H"(like all 
  Mac OS X applications) , the key-shorcut do nothing and Wish Shell 
  stay on front. If we choose 
  "Hide Wish Shell" in the Apple Menu, this works.


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: 918052ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 31. Cursor Names
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: None
title: Memory leak connected to X11, Tk and an XCursor theme
comment:
  I'm experiencing memory leaks in Tk-based applications 
  (such as demos/widget) running under X11 on SuSE 
  Linux 9, XFree86-4.3.0.1-46 and tk-8.4.4-57. I 
  discovered it only exhibits in connection with a XCursor 
  theme installed in .icons, but apparently not necessarily 
  with an arbitrary theme. So far I noticed the problem 
  only in connection with a theme called Siver, which can 
  be found at 
  http://www.kde-look.org/content/show.php?content=5533 
   
  The leak appers in the X process, not the Tk applications 
  themselves but other toolkits, like Gtk or Qt are not 
  affected by this. To reproduce it, install the Silver 
  XCursor theme and do the following: 
   
  1) run widget demo: /usr/lib/tk8.4/demos/widget  
   
  2) run top and press M to sort processes by memory 
  usage 
   
  3) move mouse pointer over links in the widget main 
  window for a while 
  (may take some time for the first time, but generally not 
  longer than 
  a minute - the loger ) 
   
  4) watch the X process memory in top. On my setup it 
  grows by about 
  1MB/5 sec. 
   
  Petr 


tkt_uuid: 919066ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 41. Photo Images
priority: 8
foundin: obsolete: 8.4.5
resolution: Remind
title: Slow processing irregular transparencies
comment:
  If you have a photo image with irregular transparent
  patches dotted around it it takes an atrociously long
  time to copy. It seems to be exponentially related to
  image size. For instance, here it takes about 2.5
  minutes of CPU time on my Athlon XP1600 to create this
  fairly compact 750x500 image by tiling a small but
  holey initial image (attached)...

  % info patchlevel
  8.4.2
  % image create photo p1 -file flip_v.gif
  p1
  % image create photo p2
  p2
  % p2 copy p1 -to 0 0 750 500
  < 150 second pause occurs here>
  %


tkt_uuid: 920695ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 5 Medium
foundin: None
resolution: Fixed
title: Documentation bug in Tk_ConfigureWidget
comment:
  In the section that describes the
  TK_CONFIG_STRING option, it is mentioned that
  memory management is done with malloc/free.
  This is clearly wrong, as memory management
  is performed by ckalloc/ckfree in Tk's core.
  This section should be corrected, and perhaps
  a warning should be added whwn old C extensions
  are ported to newer tk versions about mixing them
  with malloc/free, as memory corruption can
  occur under some operating systems (like
  windows).

  George


tkt_uuid: 922336ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Tk apps have no maximize window button under KDE-3.2.1
comment:
  After upgrading to KDE-3.2(.1), Tk applications do not  
  have "maximize window" button anymore (only 
  "minimize" and "terminate" buttons). Application 
  window can still be resized by hand, though. Other 
  toolkits, such as Gtk, don't suffer from a similar problem, 
  so I suspect some incompatibility between new kwm and 
  Tk's WM code. 
   


tkt_uuid: 922427ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 56. [grab]
priority: 5 Medium
foundin: None
resolution: None
title: Grabs get confused with multiple interpreters
comment:
  I'm not sure if this is the right category, or even if
  I'm doing something I'm not supposed to, but I got some
  very strange behaviour which I'd better report...

  If you have Tk running in two interpreters, and one of
  them executes a grab command, then if the other tries
  to do so as well an error dialogue is produced that
  cannot be killed. Here's a simple example:

  [jaspert@spirograph jaspert]$ /usr/local/ActiveTcl/bin/wish
  % info patchlevel
  8.4.6
  % set foo [interp create]
  interp0
  % $foo eval package require Tk
  8.4
  % pack [button .b -text Test -command tk_getOpenFile]
  % # Clicking button results in file dialogue
  % $foo eval grab .
  % bgerror failed to handle background error.
      Original error: grab failed: another application
  has grab
      Error in bgerror: grab failed: another application
  has grab

  The above is produced when ckicking the Test button,
  followed by OK or Cancel in the file dialogue. At this
  stage an Application Error dialogue is also produced,
  which expands when the Show Details button is hit, but
  cannot be removed. That dialogue has this text:

  grab failed: another application has grab
  grab failed: another application has grab
      while executing
  "grab $oldGrab"
      (procedure "::tk::RestoreFocusGrab" line 21)
      invoked from within
  "::tk::RestoreFocusGrab $w $data(ent) withdraw"
      (procedure "::tk::dialog::file::" line 94)
      invoked from within
  "::tk::dialog::file:: save -title {Select Log File}
  -filetypes {{{Log Files} .log} {{Text Files} .txt}
  {{All Files} *}} -defaultextension .log -parent ..."
      ("eval" body line 1)
      invoked from within
  "eval ::tk::dialog::file:: save $args"
      (procedure "tk_getSaveFile" line 5)
      invoked from within
  "tk_getSaveFile -title [mc "Select Log File"] 
  -filetypes $types -defaultextension .log -parent
  .bgerrorDialog"
      (procedure "SaveToLog" line 8)
      invoked from within
  "SaveToLog {grab failed: another application has grab
  grab failed: another application has grab
      while executing
  "grab $oldGrab"
      (procedure "::t..."
      (in namespace inscope "::tk::dialog::error" script
  line 1)
      invoked from within
  "::namespace inscope ::tk::dialog::error SaveToLog
  {grab failed: another application has grab
  grab failed: another application has grab
      while execu..."
      invoked from within
  ".bgerrorDialog.function invoke"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list $w invoke]"
      (procedure "tk::ButtonUp" line 22)
      invoked from within
  "tk::ButtonUp .bgerrorDialog.function"
      (command bound to event)

  I'm not sure what ought to happen; either the grab
  should apply to both interpreters, which I'd prefer, or
  they should be independent of one another like
  different processes.


tkt_uuid: 922666ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: obsolete: 8.4.3
resolution: Invalid
title: scrollbar: -jump option appears to not work on Windows 2000
comment:
  Hi,

  The -jump option for a scrollbar does not work on the
  Windows 2000 platform. 

  Thanks,

  Greg Pierce


tkt_uuid: 923174ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 67. Unix Window Operations
priority: 4
foundin: obsolete: 8.3.4
resolution: None
title: Can't catch loss of X server displaying slave toplevel
comment:
  If a Tcl app on one host is displaying a slave toplevel
  on another host, and the remote host logs out (thus
  yanking the X server out from under the window), then
  the Tcl app dies with XIO error 131 (Connection reset
  by peer).  Any WM_DELETE_WINDOW protocol or <Configure>
  binding on the window does not fire.  There does not
  seem to be any way in Tcl to catch and handle this
  event.  I happened to be using ActiveTcl 8.3.4.1, but I
  think it's an intrinisic Xlib problem that would affect
  any version.

  This was discussed on c.l.t and in the Tcl chatroom.


tkt_uuid: 923555ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 6
foundin: obsolete: 8.5a1
resolution: Fixed
title: [image data -format] ignores old image formats
comment:
  Lines 937-946 of tkImgPhoto.c loop
  through the photo image formats
  on the formatList seeking one which
  will support the -format.

  There's no following loop through
  the oldFormatList.  This means if
  the requested -format is implemented
  via either.

      Tk_CreateOldPhotoImageFormat()

  or
   
      #define USE_OLD_IMAGE
      Tk_CreatePhotoImageFormat()

  then it's offered stringWriteProc will
  just be ignored.

  This bug may have been around since
  the change in photo image formats (8.2?).

  We might have caught it, except none of
  the built-in photo image formats supports
  a stringWriteProc, and thus we have no
  tests of the [image data -format] command.


tkt_uuid: 923890ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: Duplicate
title: saving canvas area as PNG/BMP/GIF
comment:
  I just encountered this problem/shortcoming and had
  quite a fieldtrip working around it. I program in
  Python and generate vector graphics that the user can
  manipulate, scroll, scale blablabla. To do this I use
  Python/Tkinter. As the graphics object I use the
  canvas. To save the images I either export to
  postscript or export postscript to file (or StringIO)
  and load that with PIL (Python Image Library). Using
  PIL you can convert PS to *dozens* of formats.

  Since my enviroment is unix I never encountered a problem.

  Enter windows. Postscript itself isn't the common
  format of image to be included in documents. The canvas
  generated postscript - though Tkinter makes a big point
  of sticking to the exact PS rules - can't even be
  parsed by gimp.
  PIL does also exist on windows, BUT to parse Postscript
  it uses external programs common on unix, not included
  on windows. After doing some searching I found out
  there simply is no way to do it on windows unless you
  do screen grabs...

  my suggestion:
  making the canvas capable of exporting not only as
  postscript but also in some common image format, e.g.
  PNG, BMP or (uncompressed) GIF.

  I'd even be willing to supply a patch.


tkt_uuid: 925653ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: None
title: Win9X, i18n: codepage of error messages
comment:
  I used binaries - ActiveTcl8.4.4, 8.4.5

  This applies to non-English Win9X, for languages where
  codepages/encoding for DOS and Windows differ.

  "Console applications" in Win9X return "error text" in
  DOS codepage. Whereas "wish" always displays Error text
  in Windows codepage. This leads to unreadable Error
  messages returned to "wish" by console apps.

  (Sometimes in Activetcl it's possible to save the trace
  to journal (into logfile). In this case user/programmer
  can read saved file (in DOS-codepage) )

  This is no problem for English users (as English
  codepage is the same).
  This can be of less importance for end-user if we
  assume that there are no error messages happening in
  the "final" program.

  For example (for me particulary):
  Russian DOS codepage is cp866
  Russian WIN codepage is cp1251

  Example script:
  place these two files in the same directory and run the
  tcl-script
  this will display error, returned by VBScript
  the problem is visible on localized versions of Windows 9X

  file1: testerr.tcl
  #--------------------------------------------
  # CScript - console version of Win9X interpreter for
  VBScript, JScript et al
  exec -- cscript [file join [file dirname [info script]]
  "test.vbs"]
  #--------------------------------------------

  file2: test.vbs
  '-This is VBScript-------------------------
  Msgbox
  '---------------------------------------------


tkt_uuid: 927239ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Wish shell crashes on amsn's delete contacts
comment:
  amsn is a msn messenger clone in tcl/tk. I am using it on macosx.
  If i delete about 4 or 5 contacts from the contact list, wish crashes 
  with the following:

  If i delete like 5 contacts or so from the contact list on macosx i 
  always get a crash.

  This is what macosx says about it:

  Date/Time: 2004-02-03 23:37:28 -0400
  OS Version: 10.3.2 (Build 7D24)
  Report Version: 2

  Command: Wish Shell
  Path: /usr/bin/../.././/Applications/Utilities/Wish Shell.app/
  Contents/MacOS/Wish Shell
  Version: 8.4.5 (8.4.5)
  PID: 391
  Thread: 0

  Exception: EXC_BAD_ACCESS (0x0001)
  Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0000000d

  Thread 0 Crashed:
  0 com.apple.HIToolbox 0x927d25f8 
  SendEventToEventTargetInternal + 0x174
  1 com.apple.HIToolbox 0x927e4a88 SendEventToEventTarget 
  + 0x28
  2 com.apple.HIToolbox 0x9289b2c4 HIView::
  Click(OpaqueEventRef*) + 0x10c
  3 com.apple.HIToolbox 0x928e9744 HIViewClick + 0x38
  4 com.apple.HIToolbox 0x928b6ef0 HandleClickAsHIView + 
  0x9c
  5 com.apple.HIToolbox 0x928850ec HandleWindowClick + 
  0x204
  6 com.apple.HIToolbox 0x92866458 HandleMouseEvent + 
  0x1b8
  7 com.apple.HIToolbox 0x92828234 
  StandardWindowEventHandler + 0xa8
  8 com.apple.HIToolbox 0x927d2384 DispatchEventToHandlers 
  + 0x150
  9 com.apple.HIToolbox 0x927d25f8 
  SendEventToEventTargetInternal + 0x174
  10 com.apple.HIToolbox 0x927e4a88 SendEventToEventTarget 
  + 0x28
  11 com.apple.HIToolbox 0x927f3208 
  HandleMouseEventForWindow(OpaqueWindowPtr*, 
  OpaqueEventRef*, unsigned short) + 0x144
  12 com.apple.HIToolbox 0x927e8b24 
  HandleMouseEvent(OpaqueEventRef*) + 0x170
  13 com.apple.HIToolbox 0x927e3028 
  ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, 
  OpaqueEventRef*, void*) + 0x1e8
  14 com.apple.HIToolbox 0x927d2440 DispatchEventToHandlers 
  + 0x20c
  15 com.apple.HIToolbox 0x927d25f8 
  SendEventToEventTargetInternal + 0x174
  16 com.apple.HIToolbox 0x927e4a88 SendEventToEventTarget 
  + 0x28
  17 com.apple.HIToolbox 0x927e8980 ToolboxEventDispatcher 
  + 0x5c
  18 com.apple.HIToolbox 0x92805c6c HLTBEventDispatcher + 
  0x10
  19 com.apple.HIToolbox 0x92985ecc _RunAppModalLoop + 
  0x68
  20 com.apple.HIToolbox 0x92965d70 
  RunAppModalLoopForWindow + 0x70
  21 com.tcltk.tklibrary 0x0b07b700 Tk_MessageBoxObjCmd + 
  0x488
  22 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  23 com.tcltk.tcllibrary 0x0a031930 TclExecuteByteCode + 0x91c
  24 com.tcltk.tcllibrary 0x0a030f60 TclCompEvalObj + 0x17c
  25 com.tcltk.tcllibrary 0x0a06045c TclObjInterpProc + 0x2c0
  26 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  27 com.tcltk.tcllibrary 0x0a031930 TclExecuteByteCode + 0x91c
  28 com.tcltk.tcllibrary 0x0a030f60 TclCompEvalObj + 0x17c
  29 com.tcltk.tcllibrary 0x0a00f2c4 Tcl_EvalObjEx + 0xc0
  30 com.tcltk.tklibrary 0x0b04c100 TkInvokeMenu + 0x1e0
  31 com.tcltk.tklibrary 0x0b084e68 EventuallyInvokeMenu + 0x38
  32 com.tcltk.tcllibrary 0x0a066e30 TclServiceIdle + 0x68
  33 com.tcltk.tcllibrary 0x0a056764 Tcl_DoOneEvent + 0x180
  34 com.tcltk.tklibrary 0x0b022df0 Tk_UpdateObjCmd + 0x9c
  35 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  36 com.tcltk.tcllibrary 0x0a031930 TclExecuteByteCode + 0x91c
  37 com.tcltk.tcllibrary 0x0a030f60 TclCompEvalObj + 0x17c
  38 com.tcltk.tcllibrary 0x0a06045c TclObjInterpProc + 0x2c0
  39 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  40 com.tcltk.tcllibrary 0x0a00ee64 Tcl_EvalEx + 0x174
  41 com.tcltk.tcllibrary 0x0a067554 AfterProc + 0x8c
  42 com.tcltk.tcllibrary 0x0a066c5c TimerHandlerEventProc + 
  0x90
  43 com.tcltk.tcllibrary 0x0a056380 Tcl_ServiceEvent + 0xa4
  44 com.tcltk.tcllibrary 0x0a056750 Tcl_DoOneEvent + 0x16c
  45 com.tcltk.tklibrary 0x0b022df0 Tk_UpdateObjCmd + 0x9c
  46 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  47 com.tcltk.tcllibrary 0x0a031930 TclExecuteByteCode + 0x91c
  48 com.tcltk.tcllibrary 0x0a030f60 TclCompEvalObj + 0x17c
  49 com.tcltk.tcllibrary 0x0a06045c TclObjInterpProc + 0x2c0
  50 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  51 com.tcltk.tcllibrary 0x0a00ee64 Tcl_EvalEx + 0x174
  52 com.tcltk.tcllibrary 0x0a067554 AfterProc + 0x8c
  53 com.tcltk.tcllibrary 0x0a066c5c TimerHandlerEventProc + 
  0x90
  54 com.tcltk.tcllibrary 0x0a056380 Tcl_ServiceEvent + 0xa4
  55 com.tcltk.tcllibrary 0x0a056750 Tcl_DoOneEvent + 0x16c
  56 com.tcltk.tklibrary 0x0b022df0 Tk_UpdateObjCmd + 0x9c
  57 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  58 com.tcltk.tcllibrary 0x0a031930 TclExecuteByteCode + 0x91c
  59 com.tcltk.tcllibrary 0x0a030f60 TclCompEvalObj + 0x17c
  60 com.tcltk.tcllibrary 0x0a06045c TclObjInterpProc + 0x2c0
  61 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  62 com.tcltk.tcllibrary 0x0a00ee64 Tcl_EvalEx + 0x174
  63 com.tcltk.tcllibrary 0x0a067554 AfterProc + 0x8c
  64 com.tcltk.tcllibrary 0x0a066c5c TimerHandlerEventProc + 
  0x90
  65 com.tcltk.tcllibrary 0x0a056380 Tcl_ServiceEvent + 0xa4
  66 com.tcltk.tcllibrary 0x0a056750 Tcl_DoOneEvent + 0x16c
  67 com.tcltk.tklibrary 0x0b022df0 Tk_UpdateObjCmd + 0x9c
  68 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  69 com.tcltk.tcllibrary 0x0a031930 TclExecuteByteCode + 0x91c
  70 com.tcltk.tcllibrary 0x0a030f60 TclCompEvalObj + 0x17c
  71 com.tcltk.tcllibrary 0x0a06045c TclObjInterpProc + 0x2c0
  72 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  73 com.tcltk.tcllibrary 0x0a00ee64 Tcl_EvalEx + 0x174
  74 com.tcltk.tcllibrary 0x0a067554 AfterProc + 0x8c
  75 com.tcltk.tcllibrary 0x0a066c5c TimerHandlerEventProc + 
  0x90
  76 com.tcltk.tcllibrary 0x0a056380 Tcl_ServiceEvent + 0xa4
  77 com.tcltk.tcllibrary 0x0a056750 Tcl_DoOneEvent + 0x16c
  78 com.tcltk.tklibrary 0x0b022df0 Tk_UpdateObjCmd + 0x9c
  79 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  80 com.tcltk.tcllibrary 0x0a031930 TclExecuteByteCode + 0x91c
  81 com.tcltk.tcllibrary 0x0a030f60 TclCompEvalObj + 0x17c
  82 com.tcltk.tcllibrary 0x0a06045c TclObjInterpProc + 0x2c0
  83 com.tcltk.tcllibrary 0x0a00e5e0 TclEvalObjvInternal + 0x29c
  84 com.tcltk.tcllibrary 0x0a00ee64 Tcl_EvalEx + 0x174
  85 com.tcltk.tcllibrary 0x0a067554 AfterProc + 0x8c
  86 com.tcltk.tcllibrary 0x0a066c5c TimerHandlerEventProc + 
  0x90
  87 com.tcltk.tcllibrary 0x0a056380 Tcl_ServiceEvent + 0xa4
  88 com.tcltk.tcllibrary 0x0a056750 Tcl_DoOneEvent + 0x16c
  89 com.tcltk.tklibrary 0x0b02d56c Tk_MainLoop + 0x14
  90 com.tcltk.tklibrary 0x0b04acf4 Tk_MainEx + 0x320
  91 com.tcltk.wish 0x00015db0 main + 0x11c
  92 com.tcltk.wish 0x000159c4 _start + 0x188 (crt.c:267)
  93 com.tcltk.wish 0x00015838 start + 0x30

  Thread 1:
  0 libSystem.B.dylib 0x9000b30c select + 0xc
  1 com.tcltk.tklibrary 0x0b08a8cc NotifierThreadProc + 0x1c0
  2 libSystem.B.dylib 0x900247e8 _pthread_body + 0x28

  PPC Thread State:
  srr0: 0x927d25f8 srr1: 0x0200f030 vrsave: 
  0x00000000
  cr: 0x24024222 xer: 0x00000004 lr: 0x927d25f8 ctr: 
  0x90001fa0
  r0: 0x927d25f8 r1: 0xbfffb2b0 r2: 0x00000000 r3: 
  0x00000000
  r4: 0x00000000 r5: 0x003ed4b0 r6: 0x00000001 r7: 
  0x00000001
  r8: 0x00000003 r9: 0x00000000 r10: 0xa27f8634 r11: 
  0x44024222
  r12: 0x90001fa0 r13: 0x00000001 r14: 0x00000001 r15: 
  0x00000000
  r16: 0x00000000 r17: 0x00000001 r18: 0x00000000 r19: 
  0x00000000
  r20: 0x00000002 r21: 0x00000000 r22: 0x08f4dfa0 r23: 
  0x08f48ba0
  r24: 0xbfffb7a0 r25: 0xffffd96e r26: 0x08f20fc0 r27: 
  0x00000001
  r28: 0x08f1a840 r29: 0x08f1a840 r30: 0x003d35b0 r31: 
  0x927d248c

  Binary Images Description:
  0x1000 - 0x16fff com.tcltk.wish 8.4.5 /usr/bin/../.././/
  Applications/Utilities/Wish Shell.app/Contents/MacOS/Wish Shell
  0x1722000 - 0x1728fff libtls1.50.dylib /Users/espectro/Library/
  Application Support/amsn/plugins/tls1.50/libtls1.50.dylib
  0xa000000 - 0xa089fff com.tcltk.tcllibrary 8.4.5 /Library/
  Frameworks/Tcl.framework/Versions/8.4/Tcl
  0xb000000 - 0xb0b2fff com.tcltk.tklibrary 8.4.5 /Library/
  Frameworks/Tk.framework/Versions/8.4/Tk
  0x78160000 - 0x7818dfff libssl.0.9.dylib /usr/lib/libssl.0.9.dylib
  0x880a0000 - 0x880a7fff libLW8Utils.dylib /System/Library/
  Printers/Libraries/libLW8Utils.dylib
  0x88170000 - 0x881affff libLW8Converter.dylib /System/Library/
  Printers/Libraries/libLW8Converter.dylib
  0x882a0000 - 0x882c6fff libConverter.dylib /System/Library/
  Printers/Libraries/libConverter.dylib
  0x8fe00000 - 0x8fe4ffff dyld /usr/lib/dyld
  0x90000000 - 0x90122fff libSystem.B.dylib /usr/lib/
  libSystem.B.dylib
  0x90190000 - 0x9023dfff com.apple.CoreFoundation 6.3 (299)
  /System/Library/Frameworks/CoreFoundation.framework/
  Versions/A/CoreFoundation
  0x90280000 - 0x904f9fff com.apple.CoreServices.CarbonCore 
  10.3.2 /System/Library/Frameworks/CoreServices.framework/
  Versions/A/Frameworks/CarbonCore.framework/Versions/A/
  CarbonCore
  0x90570000 - 0x905ddfff com.apple.framework.IOKit 1.3 (???)
  /System/Library/Frameworks/IOKit.framework/Versions/A/
  IOKit
  0x90610000 - 0x90699fff com.apple.CoreServices.OSServices 3.0 
  (3.0.0) /System/Library/Frameworks/CoreServices.framework/
  Versions/A/Frameworks/OSServices.framework/Versions/A/
  OSServices
  0x90700000 - 0x90700fff com.apple.CoreServices 10.3 (???)
  /System/Library/Frameworks/CoreServices.framework/
  Versions/A/CoreServices
  0x90720000 - 0x90787fff com.apple.audio.CoreAudio 2.1.2
  /System/Library/Frameworks/CoreAudio.framework/Versions/
  A/CoreAudio
  0x907f0000 - 0x907f9fff com.apple.DiskArbitration 2.0
  /System/Library/PrivateFrameworks/
  DiskArbitration.framework/Versions/A/DiskArbitration
  0x90810000 - 0x90810fff com.apple.ApplicationServices 1.0 (???)
  /System/Library/Frameworks/ApplicationServices.framework/
  Versions/A/ApplicationServices
  0x90910000 - 0x90983fff com.apple.DesktopServices 1.2
  /System/Library/PrivateFrameworks/
  DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
  0x90d00000 - 0x90d19fff com.apple.SystemConfiguration 1.4.1 
  (???) /System/Library/Frameworks/
  SystemConfiguration.framework/Versions/A/SystemConfiguration
  0x90d40000 - 0x90d40fff com.apple.Carbon 10.3 (???)
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Carbon
  0x910b0000 - 0x910fffff com.apple.bom 1.2.3 (62.1)
  /System/Library/PrivateFrameworks/Bom.framework/Versions/
  A/Bom
  0x912a0000 - 0x912bdfff com.apple.audio.SoundManager 3.8
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/CarbonSound.framework/Versions/A/CarbonSound
  0x912e0000 - 0x912f7fff com.apple.LangAnalysis 1.5.4
  /System/Library/Frameworks/ApplicationServices.framework/
  Versions/A/Frameworks/LangAnalysis.framework/Versions/A/
  LangAnalysis
  0x91320000 - 0x913defff ColorSync /System/Library/Frameworks/
  ApplicationServices.framework/Versions/A/Frameworks/
  ColorSync.framework/Versions/A/ColorSync
  0x91460000 - 0x91473fff com.apple.speech.synthesis.framework 
  3.2 /System/Library/Frameworks/ApplicationServices.framework/
  Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/
  SpeechSynthesis
  0x914a0000 - 0x91509fff com.apple.htmlrendering 1.1.2
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering
  0x91560000 - 0x91619fff com.apple.QD 3.4.62 (???)
  /System/Library/Frameworks/ApplicationServices.framework/
  Versions/A/Frameworks/QD.framework/Versions/A/QD
  0x91670000 - 0x916a8fff com.apple.AE 1.3.2 /System/Library/
  Frameworks/ApplicationServices.framework/Versions/A/
  Frameworks/AE.framework/Versions/A/AE
  0x916e0000 - 0x91773fff com.apple.print.framework.PrintCore 3.1
  /System/Library/Frameworks/ApplicationServices.framework/
  Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
  0x917e0000 - 0x917f0fff com.apple.speech.recognition.framework 
  3.3 /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/SpeechRecognition.framework/Versions/A/
  SpeechRecognition
  0x91810000 - 0x9182afff com.apple.openscripting 1.2.1 (???)
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/OpenScripting.framework/Versions/A/OpenScripting
  0x91850000 - 0x91860fff com.apple.ImageCapture 2.1.0
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/ImageCapture.framework/Versions/A/ImageCapture
  0x91890000 - 0x9189cfff com.apple.help 1.0.1 /System/Library/
  Frameworks/Carbon.framework/Versions/A/Frameworks/
  Help.framework/Versions/A/Help
  0x918c0000 - 0x918cdfff com.apple.CommonPanels 1.2.1 (1.0)
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/CommonPanels.framework/Versions/A/CommonPanels
  0x918f0000 - 0x9193dfff com.apple.print.framework.Print 3.0 (3.1)
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/Print.framework/Versions/A/Print
  0x91990000 - 0x9199bfff com.apple.securityhi 1.2 (90)
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/SecurityHI.framework/Versions/A/SecurityHI
  0x919c0000 - 0x91a32fff com.apple.NavigationServices 3.3
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/NavigationServices.framework/Versions/A/
  NavigationServices
  0x91ab0000 - 0x91ac4fff libCGATS.A.dylib /System/Library/
  Frameworks/ApplicationServices.framework/Versions/A/
  Frameworks/CoreGraphics.framework/Versions/A/Resources/
  libCGATS.A.dylib
  0x91ae0000 - 0x91aebfff libCSync.A.dylib /System/Library/
  Frameworks/ApplicationServices.framework/Versions/A/
  Frameworks/CoreGraphics.framework/Versions/A/Resources/
  libCSync.A.dylib
  0x91b10000 - 0x91b2afff libPDFRIP.A.dylib /System/Library/
  Frameworks/ApplicationServices.framework/Versions/A/
  Frameworks/CoreGraphics.framework/Versions/A/Resources/
  libPDFRIP.A.dylib
  0x91b50000 - 0x91b5ffff libPSRIP.A.dylib /System/Library/
  Frameworks/ApplicationServices.framework/Versions/A/
  Frameworks/CoreGraphics.framework/Versions/A/Resources/
  libPSRIP.A.dylib
  0x91b80000 - 0x91b93fff libRIP.A.dylib /System/Library/
  Frameworks/ApplicationServices.framework/Versions/A/
  Frameworks/CoreGraphics.framework/Versions/A/Resources/
  libRIP.A.dylib
  0x91bb0000 - 0x91d44fff com.apple.QuickTime 6.5.0
  /System/Library/Frameworks/QuickTime.framework/QuickTime
  0x92070000 - 0x92096fff com.apple.FindByContent 1.4 (1.2)
  /System/Library/Frameworks/ApplicationServices.framework/
  Versions/A/Frameworks/FindByContent.framework/Versions/A/
  FindByContent
  0x920c0000 - 0x922a6fff com.apple.security 2.1 (163.1)
  /System/Library/Frameworks/Security.framework/Versions/A/
  Security
  0x92430000 - 0x92468fff com.apple.LaunchServices 10.3 (84)
  /System/Library/Frameworks/ApplicationServices.framework/
  Versions/A/Frameworks/LaunchServices.framework/Versions/A/
  LaunchServices
  0x92650000 - 0x926f3fff libcrypto.0.9.dylib /usr/lib/
  libcrypto.0.9.dylib
  0x92740000 - 0x92777fff com.apple.CFNetwork 1.2.1 (7)
  /System/Library/Frameworks/CoreServices.framework/
  Versions/A/Frameworks/CFNetwork.framework/Versions/A/
  CFNetwork
  0x927d0000 - 0x92b53fff com.apple.HIToolbox 1.3.1 (???)
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/HIToolbox.framework/Versions/A/HIToolbox
  0x92d30000 - 0x92d80fff com.apple.HIServices 1.4.0 (0.0.1d1)
  /System/Library/Frameworks/ApplicationServices.framework/
  Versions/A/Frameworks/HIServices.framework/Versions/A/
  HIServices
  0x935d0000 - 0x938a6fff com.apple.CoreGraphics 1.203.12 (???)
  /System/Library/Frameworks/ApplicationServices.framework/
  Versions/A/Frameworks/CoreGraphics.framework/Versions/A/
  CoreGraphics
  0x939a0000 - 0x939b4fff libcups.2.dylib /usr/lib/libcups.2.dylib
  0x939d0000 - 0x939d4fff libmathCommon.A.dylib 
  /usr/lib/system/libmathCommon.A.dylib
  0x94060000 - 0x9407ffff com.apple.WebServices 1.1.0
  /System/Library/Frameworks/CoreServices.framework/
  Versions/A/Frameworks/WebServicesCore.framework/Versions/A/
  WebServicesCore
  0x945b0000 - 0x945b9fff libz.1.dylib /usr/lib/libz.1.dylib
  0x94610000 - 0x9462afff libresolv.9.dylib /usr/lib/
  libresolv.9.dylib
  0x94650000 - 0x946affff com.apple.SearchKit 1.0.2
  /System/Library/Frameworks/CoreServices.framework/
  Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
  0x94b20000 - 0x94babfff com.apple.ink.framework 1.1 (54.4)
  /System/Library/Frameworks/Carbon.framework/Versions/A/
  Frameworks/Ink.framework/Versions/A/Ink
  0x968d0000 - 0x969b2fff libicucore.A.dylib /usr/lib/
  libicucore.A.dylib
  0x96a20000 - 0x96ae2fff libcrypto.0.9.7.dylib /usr/lib/
  libcrypto.0.9.7.dylib
  0x96b40000 - 0x96b6efff libssl.0.9.7.dylib /usr/lib/
  libssl.0.9.7.dylib
  0x96bf0000 - 0x96c7ffff ATS /System/Library/Frameworks/
  ApplicationServices.framework/Versions/A/Frameworks/
  ATS.framework/Versions/A/ATS

  and this is what amsn/wish say about it:

  /usr/bin/wish: line 2: 391 Bus error "$(dirname )/../
  .././/Applications/Utilities/Wish Shell.app/Contents/MacOS/Wish 
  Shell" "$@"


tkt_uuid: 927492ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 62. Geometry Functions
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Fixed
title: WinTk:winfo screenwidth, etc,don't respect resolution change
comment:
  When I change the resolution on my Windows XP machine,
  the result of 'winfo screenwidth .' doesn't change. 
  So, there's no way a Tk application can learn that the
  screen it's operating on is now a different size.


tkt_uuid: 928413ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 9 Immediate
foundin: obsolete: 8.4.6
resolution: Fixed
title: Panedwindow crash due to stale pointer
comment:
  The panedwindow can hold onto a stale tkwin pointer
  after the window has been destroyed.  The following
  script will illustrate the problem:

  panedwindow .pw
  pack .pw -fill both -expand 1
  label .pw.l1 -text Label1
  label .pw.l2 -text Label2
  label .pw.l3 -text Label3
  .pw add .pw.l1
  .pw add .pw.l3
  .pw add .pw.l2 -before .pw.l3
  puts stdout [.pw paneconfigure .pw.l2 -before]
  destroy .pw.l3
  button .thisisnotwhatitshouldbe -text "This Is Not what
  it should be!"
  pack .thisisnotwhatitshouldbe 
  puts stdout [.pw paneconfigure .pw.l2 -before]
  destroy .thisisnotwhatitshouldbe
  puts stdout [.pw paneconfigure .pw.l2 -before]


  As you can see, the wrong widget path is reported for
  the -before option.  In a more complex interaction,
  this stale reference can lead to a crash.

  The attached patch will fix the problem.
  -Brian


tkt_uuid: 928527ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: None
resolution: Out of Date
title: determining if a window has been raised or lowered
comment:
  I just spent a day try to figure out the following:
  I have a main window and multiple other smaller
  configuration windows that are open in parallel to the
  main window. The following behaviour of the main window
  would be good:
  * iconize main window -> all config windows disappear
  * de-iconize window -> config windows reappear
  * move main window -> config windows move also
  * lower main window -> config windows lower themselves also
  * raise main window -> config windows also raise

  The points 1 and 2 can be done (e.g. using the wm group
  command). The 3rd point can be done with the help of
  the binding to the Configure-event.
  But it seems there is no direct way of determining if a
  window has explicitly been raised or lowered. (It seems
  no explicit event is sent for the event of changing the
  stacking order on the X winow system. I verified this
  with using /usr/X11R6/bin/xev). 
  Two events are sent, though: VisibilityNotify and
  Expose. But they are sent in other cases also. 

  It seems the only way to determine if a window has been
  raised or lowered is to know its index and/or
  neighbouring windows in the stacking level list. This
  list is attained by (recursively) calling the
  XQueryTree function.

  I tested the idea and it works well.

  my suggestion:

  adding a funtion to the winfo command:
  &nbsp;&nbsp;winfo stacklevel $windowid
  returns the stacklevel of a window

  and
  &nbsp;&nbsp;winfo stacklevel $windowid -get prevneighbour
  &nbsp;&nbsp;winfo stacklevel $windowid -get nextneighbour
  returns the window ids of the previous and next neighbours

  (calling winfo stacklevel without a windowid could
  return the complete list of all window ids...)

  I could supply a patch.


tkt_uuid: 929933ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 4
foundin: None
resolution: None
title: Aqua mac OS X-focus problem in text widget with dock
comment:
  How to reproduce the bug
  Execute that script...click on .t window, try to write something in .f 
  first text widget
  put that window in the dock (.f)
  click in the dock to reveat the window
  You can't write in .f anymore...You can't bring the focus to the text 
  widget. You have to switch to .t and get back to .f

  frame .f -width 300 ;
  update idletasks ;
  text .c1 -background white -width 15 -height 3 -wrap word -font 
  bboldf -borderwidth 0 -relief solid -highlightthickness 0 
  -exportselection 1
  text .c2 -background white -width 15 -height 3 -wrap word -font 
  bboldf -borderwidth 0 -relief solid -highlightthickness 0 
  -exportselection 1
  .c2 configure -state disabled
  pack .f ;
  pack .c1 -side left -expand true -fill both -padx 1 -pady 1;
  pack .c2 -side right -expand true -fill both -padx 1 -pady 1;
  toplevel .t
  entry .t.e
  pack .t.e

  Comment from Jim:
  I put printf in TkMacOSXProcessWindowEvent, which is where we 
  handle window Activation & Deactivation.  What I see is:

  Normal case: when you just click on .t or . to foreground a window 
  you first get the Deactivate event for the window that is going to 
  the background, then the Activate event for the new window.

  Hide/Reveal case: when you hide the window, then on Reveal, you 
  first get the Activate event for the revealed window, THEN the 
  Deactivate window for the previous foreground window.

  So we end up with nobody having the focus...  %$^#$%@#!#@$


tkt_uuid: 931231ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 70. Event Loop
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Tcl_DoOneEvent blocks when there is modal dialog
comment:
  Tcl_DoOneEvent blocks when there is modal dialog 
  I am using C application with Tcl/Tk front end GUI. I use 
  tcl84.lib and tk84.lib for Windows 2000 platform. I 
  periodically use following to update display and get user 
  input.
  while (Tcl_DoOneEvent(TCL_ALL_EVENTS | 
  TCL_DONT_WAIT)); 

  But this call blocks and never returns when I have modal 
  dialog open in GUI. So when user opens modal dialog, I 
  cannot update GUI display from program. When I used 
  TCL_DONT_WAIT flag, I assumed that this will return 
  immediately, if there is no event pending. But it does not 
  work that way. Can anybody explain why this is not 
  working and how to make it work?
  Thanks,
  Niraj
   


tkt_uuid: 931324ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 4
foundin: None
resolution: None
title: Bwidget&TKAqua&Tabs--Mistake betwen tabs
comment:
  Hi!

  I have another big problem with TKAqua and Bwidget on Mac OS X.
  The problem is with ScrolledFrame, ScrolledWindow and Tabs (I 
  don't have this problem without scrolledframe&scrolledwindow).
  See my example script.
  After showing the tabs, if I switch to another application or another 
  window (in the same program), the tabs get mistaken. Items from 
  tabs1 go to tabs2, etc.
  Sometimes, after a big delay (or after scrolling), the window get 
  reloaded and the window is ok.
  This is the biggest bug...

  Another bug is, at the first time we click on Tab2, the ***Test label 
  in tab 2*** start at the left at the window and get center AFTER. 
  When we have a tab with like 20 items, we all see them moving!!

  **Linux and Windows users don't have theses bugs.

  ---begin tabstest.tcl---

  package require BWidget

  proc test_tabs {} {
  NoteBook .nb
  .nb insert 0 tab1 -text "Tab 1"
  .nb insert 1 tab2 -text "Tab 2"


  set tab [.nb getframe tab1]
  ScrolledWindow $tab.sw
  ScrollableFrame $tab.sw.sf -constrainedwidth 1
  $tab.sw setwidget $tab.sw.sf
  pack $tab.sw -anchor n -side top -expand true -fill both
  set tab [$tab.sw.sf getframe]
  label $tab.l1 -text "-- Just a test label --"
  pack $tab.l1 -side top
  label $tab.l2 -text "-- Just a test label --"
  pack $tab.l2 -side top
   checkbutton $tab.l3 -text "Zoum" -variable prueba
   checkbutton $tab.l4 -text "HOLY HOLY" -variable prueba
   pack $tab.l3 -side top
   pack $tab.l4 -side top


  set tab [.nb getframe tab2]
  ScrolledWindow $tab.sw
  ScrollableFrame $tab.sw.sf -constrainedwidth 1
  $tab.sw setwidget $tab.sw.sf
  pack $tab.sw -anchor n -side top -expand true -fill both
  set tab [$tab.sw.sf getframe]
  label $tab.l1 -text "***** TEST LABEL IN TAB 2 ****"
  pack $tab.l1 -side top
  label $tab.l2 -text "***** TEST LABEL IN TAB 2 ****"
  pack $tab.l2 -side top

  .nb compute_size
  .nb raise tab1
  pack .nb
  }

  test_tabs

  ---end tabstest.tcl---


tkt_uuid: 932155ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 8
foundin: obsolete: 8.4.6
resolution: Fixed
title: Sash misbehavior
comment:
  If you have more than 1 sash (i.e more than 2 panes)
  and a drag is performed on one sash (causing the proxy
  to be placed) and then, on a different sash, a
  <Button-1> event followed by a <ButtonRelease-1> event
  with no intervening <B1-Motion> event, the sash will
  jump to the last proxy location.

  To fix this, the <Button-1> event must initialize the
  proxy location so that if there is no drag, the button
  release will cause no movement of the sash.  This can
  be done by explicitly calling the DragSash function
  from the MarkSash function:

  proc ::tk::panedwindow::MarkSash {w x y proxy} {
      set what [$w identify $x $y]
      if { [llength $what] == 2 } {
  foreach {index which} $what break
  if { !$::tk_strictMotif || [string equal $which
  "handle"] } {
      if {!$proxy} { $w sash mark $index $x $y }
      set ::tk::Priv(sash) $index
      foreach {sx sy} [$w sash coord $index] break
      set ::tk::Priv(dx) [expr {$sx-$x}]
      set ::tk::Priv(dy) [expr {$sy-$y}]
      # Do this to init the proxy location
      DragSash $w $x $y $proxy
  }
      }
  }

  This bug exists on the top of trunk (8.5) as well.

  -Brian


tkt_uuid: 934524ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: Fixed
title: Wish doesn't process fronting clicks
comment:
  When you launch Wish the toplevel appears in front of
  the console.  Under OS 9 I could click and drag on the
  titlebar of the console to move it out from under the
  toplevel.  Under OS X this just raises the console
  window; you have to click and drag again to move the
  window.  OS 9 had a resource flag for whether apps got
  fronting clicks or not, but I don't know if OS X has
  anything equivalent or not.

  This is with TclTkAquaBI 8.4.5 (I think, I'm not at my
  Mac right now) under Panther 10.3.3.

  This was initially reported on the MACTCL mailing list,
  to which Jim Ingham replied:

  On 9 we handled ALL events explicitly in Tk.  But on X,
  there are some events that we let the system take care
  of.  The Title bar is one of these - we had to do this
  to get the stop-lights to work. I'm a little surprised
  that this doesn't "just work", but maybe there is
  something we can tell the standard window handler to
  get it to have this behavior.

  Can you file a bug about this so we don't forget?


tkt_uuid: 934634ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Duplicate
title: Tcl_DoOneEvent blocks when dialog box is open
comment:
  I am using C application with Tcl/Tk front end. I use 
  tcl84.lib and tk84.lib for Windows 2000 platform. I 
  periodically use following to refresh display and get user 
  input.
  while (Tcl_DoOneEvent(TCL_ALL_EVENTS | 
  TCL_DONT_WAIT)); 

  But this call blocks and never returns when I have modal 
  dialog (like file open or any other dialog) open in GUI. 
  When I used TCL_DONT_WAIT flag, I 
  assumed that this will return immediately, if there is no 
  event pending. But it does not work that way. Can 
  anybody explain why this is not working and how to 
  make it work?
  Thanks,
  Niraj
   


tkt_uuid: 935242ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Invalid
title: namespace ::twapi lingers under Linux (Unix?)
comment:
  Observed
  ========

  > tclsh
  % set tcl_platform(os)
  Linux
  % namespace exists ::twapi
  0
  % package require Tk
  8.4
  % namespace exists ::twapi
  1

  Expected
  ========

  No traces of platform-specific extensions on platforms
  where they are useless.

  Erik Leunissen


tkt_uuid: 936195ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 55. [focus]
priority: 6
foundin: None
resolution: None
title: Reset focus to embedded windows (bug fix)
comment:
  This patch provides a fix for handling bogus FocusOut
  events as can be observed by using an embedded
  application on certain X11 Window managers.

  This may be connected to the bugs #740565 and/or #480158.

  This patch is against Tk8.4.1 and confirmed to work on
  the following Unix systems:
  SLES 7 + 8 (ia32);
  RHEL 2.1 + 3.0 (ia32);
  SLES 8 (s390);
  SUN Solaris 5.7, 5.8, 5.9 (Sparc);
  AIX 4.3, 5.1, 5.2;
  HPUX 11+ (PA-Risc);
  Tru64 5.1;

  Not tested on other operating systems. This patch was
  originally developed by krischan (SF id).


tkt_uuid: 937783ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Invalid
title: Win TK menu binding does not register
comment:
  Tcl/Tk 8.4.6.0 for Windows (ActiveTcl Binary
  Distribution) seems to not register bindings to menu.
  However, linux version of Tcl/Tk seems to work fine.

  Code:

  frame .mbar -relief raised
  menubutton .mbar.m1_button -text "Test1" -menu
  .mbar.m1_button.m1
  menu .mbar.m1_button.m1
  pack .mbar -side top -fill x
  pack .mbar.m1_button -side left
  .mbar.m1_button.m1 add command -label "Test1 MenuItem A"
  .mbar.m1_button.m1 add command -label "Test1 MenuItem B"
  bind .mbar.m1_button.m1 <Enter> {exit}


  Problem:

  Running this code in Linux Tcl/Tk, when opening the
  menu and mousing over the menuitems, the program will
  exit, as expected. But running this code under Win
  Tcl/Tk, mousing over the menuitems, nothing happens!!


tkt_uuid: 939389ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Win Tk can lose clipboard data on exit (bug fix)
comment:
  When wish84.exe runs the following script saved as 
  "a.tcl", the clipboard on Windows system doesn't 
  have the text "foo":

  # run as "wish84.exe a.tcl"
  clipboard append foo
  exit

  TkpCloseDisplay() function (win/tkWinX.c) tries to 
  render the clipboard data before exiting wish84.exe 
  if dispPtr->clipWindow is not NULL. But, 
  TkCloseDisplay() function (generic/tkWindow.c) 
  calls TkClipCleanup() function before calling 
  TkpCloseDisplay() function so that dispPtr->clipWindow 
  in TkpCloseDisplay() is always NULL.
  TkWinClipboardRender() function (win/tkWinClipboard.c) 
  is only called when WM_RENDERFORMAT message is sent.


tkt_uuid: 940117ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 9 Immediate
foundin: obsolete: 8.4.13
resolution: Fixed
title: Bwidget&TKAqua&Tabs--Problem with entry
comment:
  Try to write something in the "entry", or just give focus to the 
  entry. And then switch tabs...
  The entry will be include in the next tabs...! Very strange
  We don't have that problem on Linux or Windows..

  Tk Aqua 8.4.5
  Mac OS X



  ---begin tabstest.tcl---

  package require BWidget

  proc test_tabs {} {
  NoteBook .nb
  .nb insert 0 tab1 -text "Tab 1"
  .nb insert 1 tab2 -text "Tab 2"


  set tab [.nb getframe tab1]
  ScrolledWindow $tab.sw
  ScrollableFrame $tab.sw.sf -constrainedwidth 1
  $tab.sw setwidget $tab.sw.sf
  pack $tab.sw -anchor n -side top -expand true -fill both
  set tab [$tab.sw.sf getframe] 
  entry $tab.l1 -text "-- Just a test label --"
  pack $tab.l1 -side top
  label $tab.l2 -text "-- Just a test label --"
  pack $tab.l2 -side top
  checkbutton $tab.l3 -text "Zoum" -variable prueba
  checkbutton $tab.l4 -text "HOLY HOLY" -variable prueba
  pack $tab.l3 -side top
  pack $tab.l4 -side top


  set tab [.nb getframe tab2]
  ScrolledWindow $tab.sw
  ScrollableFrame $tab.sw.sf -constrainedwidth 1
  $tab.sw setwidget $tab.sw.sf
  pack $tab.sw -anchor n -side top -expand true -fill both
  set tab [$tab.sw.sf getframe]
  label $tab.l1 -text "***** TEST LABEL IN TAB 2 ****"
  pack $tab.l1 -side top
  label $tab.l2 -text "***** TEST LABEL IN TAB 2 ****"
  pack $tab.l2 -side top

  .nb compute_size
  .nb raise tab1
  pack .nb
  }

  test_tabs

  ---end tabstest.tcl---


tkt_uuid: 940209ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Out of Date
title: bind documentation refers to X11 docs
comment:
  The [bind] documentation refers the reader to any
  X-windows documentation to learn about what it means to
  bind to <Map>, <Unmap>, <Visibility>, etc. events. 
  These should at least be explained briefly in Tk's
  documentation, even if external resources are suggested
  for further reading.


tkt_uuid: 940220ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 62. Geometry Functions
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: None
title: wm geometry contradictions (and inadequately documented
comment:
  The documentation of "wm geometry $win" doesn't make
  clear whether the quantities referred to are relative
  to the toplevel window's border or the window manager
  decoration (titlebar, menubar with configure -menu, etc).

  In fact on windows, the returned value is:

  contentsWidth x contentsHeight
  + decorationLeft + decorationTop

  which is rather surprising.  This means to find the
  total number of vertical pixels covered by the
  toplevel, including any menubar/titlebar/border, we
  must perform a complex calculation (and must actually
  assume the bottom edge and right edge decoration are
  the same thickness as the left edge decoration).  So,
  here's a function to determine, as best possible, the
  total geometry covered by a window:

  proc default::totalGeometry {{w .}} {
      set geom [wm geometry $w]
      regexp -- {([0-9]+)x([0-9]+)\+([0-9]+)\+([0-9]+)}
  $geom -> \
        width height decorationLeft decorationTop
      set contentsTop [winfo rooty $w]
      set contentsLeft [winfo rootx $w]
      
      # Measure left edge, and assume all edges except
  top are the
      # same thickness
      set decorationThickness [expr {$contentsLeft -
  $decorationLeft}]
      
      # Find titlebar and menubar thickness
      set menubarThickness [expr {$contentsTop -
  $decorationTop}]
      
      incr width [expr {2 * $decorationThickness}]
      incr height $decorationThickness
      incr height $menubarThickness
      
      return [list $width $height $decorationLeft
  $decorationTop]
  }

  Nowhere in the documentation are these issues/terms
  made clear.  So, while I know the above works on
  Windows, I really cannot be sure it works on other
  platforms.  The documentation should be fixed (and this
  proc could be used as an example, perhaps).


tkt_uuid: 940760ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 8
foundin: obsolete: 8.5a4
resolution: Out of Date
title: TkAqua: menu rebuild bug
comment:
  This simple test case illustrates a bug in TkAqua's
  menu handling:

  menu .menu
  menu .menu.one

  proc rebuild {} {
      destroy .menu.one.two
      menu .menu.one.two
      for {set i 0} {$i < 10} {incr i} {
          .menu.one.two add command -label "item $i" \
           -command "puts $i"
      }
      .menu.one.two add command -label "rebuild" \
          -command rebuild
  }

  rebuild

  .menu.one add cascade -menu .menu.one.two -label "sub"
  .menu.one add command -label dummy
  .menu add cascade -menu .menu.one -label "test"
  . configure -menu .menu

  Paste the above code into TkAqua's console, click on
  the main window to
  have the 'test' menu appear in the main OS menubar and
  then go down to the
  submenu and select 'rebuild'.  This command will
  destroy the menu, but
  then rebuild it as is so everything should be the same.
   However, if you
  return to the menubar and try to post the submenu
  again, you'll find it
  won't post.  Now click over to the Finder, or some
  other application and
  then back to Wish, and you'll find the menu now works!

  Somehow the menu->submenu connection is forgotten when
  the menu is rebuilt, and is only set correctly again
  when we switch context from/to TkAqua.


tkt_uuid: 942320ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: Tk, Xft, text and long lines
comment:
  Andreas Leitgeb reports on c.l.t:

  I've got some application, that uses Tk's text-widget and
  inserts lines which are sometimes very long (10000
  chars or more)
  with wrapping turned off (-wrap none).
  [...]
  Recently I tried  Xft, and noticed that these
  long lines wrap around at 65536 pixels (about 9362
  chars with my
  default font). The next characters overwrite the start
  of the line.
  This does not happen with xft disabled.


tkt_uuid: 943110ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Fixed
title: tk_getOpenFile on windows and rogue events
comment:
  I previously posted a bug (219985) on this matter, but
  I see that a resolution has still not presented itself.

  The problem:

  Double clicking on a windows filebrowser sends extra
  events to the window underneath the filebrowser. Let me
  make this clear... THIS IS A WINDOWS BUG!

  However, taking a pragmatic view it's still a right
  pain and something that needs to be solved in Tk. This
  problem doesn't seem to happen when using modern MS
  applicants (although IIRC it used to be noticable in
  the old MS help program), so clearly their own
  libraries work around this and "gobble up" the rogue
  events.

  A quick demonstration make it evident. From an
  interactive wish shell, type in the following:

  button .b -text "press me" -command ".b configure -text
  pressed" -width 100 -height 30
  pack .b

  Ie create a huge button.

  Now type "tk_getOpenFile" and position the dialogue
  over the top of the button. Double click on a file
  noting the location of the mouse click at the time. You
  will see that if you double clicked on something which
  was physically over the top of the button then the
  button text has now changed to "pressed". That button
  could have done anything, so this is a serious
  interface problem.

  The previous ticked had an answer referring to a news
  posting:

  http://groups.google.com/groups?oi=djq&selm=an_496001244

  This gives the impression that the 1.5 clicks are
  consumed, and the ButtonRelease makes it through to the
  underlying window. This is not true.

  Try typing:

  bind .b <ButtonPress-1> {puts down}
  bind .b <ButtonRelease-1> {puts up}
  tk_getOpenFile

  and then trying once more.

  The button gets BOTH down and up events, making it
  totally impossible to programmatically (from tcl)
  determine the cause of the problem.

  The solution? We previously had a local patch to Tk
  that after the tk call to the native windows
  filebrowser all button events for a short period of
  time would be silently consumed. I acknowledge that
  this is a total hack, but it seems a necessary evil. I
  will see if I can dredge up this old code (but I have
  subsequently changed jobs since then so I may not be
  able to access it).

  Naturally I would prefer a cleaner solution if one can
  be found.

  James


tkt_uuid: 945409ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 30. Color Names
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: special windows / OSX colors not documented
comment:
  The special colors for Windows and OS X seem not to be
  documented.

  SystemButtonFace SystemButtonText SystemDisabledText
  SystemHighlight
      SystemHightlightText SystemMenu SystemMenuText
  SystemScrollbar
      SystemWindow SystemWindowFrame SystemWindowText

  Probably info about them should be added to colors.n

  Michael


tkt_uuid: 946007ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: None
priority: 5 Medium
foundin: None
resolution: None
title: TkAqua: menu labels can't start with a "-"
comment:
  In TkAqua, menu labels that start with a dash charracter cause the 
  menu item to be seen as a seperator item.
  This occurs if the label is set during the menu entry addition, or 
  using an "entryconfigure -label" command. I assume this was 
  added as a convenience feature, but it seems to be unique to 
  TkAqua, and I couldn't find it documented anywhere. 

  I recommend TkAqua stick to cross-platform standards as much as 
  possible. i understand that the substantial ammount of re-coding 
  that is going on to make TkAqua introduces a temptation to add 
  "improvements", but these should be put into the core, not the 
  TkAqua.


tkt_uuid: 946106ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: XP visual styles support for native Tk widgets...
comment:
  I simply post here an updated version of my patch that adds 
  drawing of native tk widgets (button, radiobutton, 
  checkbutton, spinbox, entry) using the XP style engine. 
  This patch adds a new option to all these widgets (-stylexp 
  boolean) which controls the drawing. 
   


tkt_uuid: 946152ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 30. Color Names
priority: 5 Medium
foundin: TIP Implementation
resolution: None
title: TIP 154: Add Named Colors to Tk
comment:
  Attached is the first revision of a patch for TIP 154
  to add named colors to Tk accessible at the Tcl level.

  As it's my first-ever patch, and I'm not the finest C
  programmer in the world, please be kind and
  constructive. 0-]


tkt_uuid: 947147ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Works For Me
title: win98: page fault when maximizing a window
comment:
  test code:

  grid [canvas .c] -row 0 -column 0 -sticky nswe
  grid rowconfigure . 0 -weight 1
  grid columnconfigure . 0 -weight 1

  now click on the "maximize" button in the upper right 
  corner of "."

  I get a page fault

  this doesn't happen if .c is a text widget, if either the 
  weight of the row or column configure is 0, or if 
  the "sticky" setting is not "nswe".


tkt_uuid: 949477ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Duplicate
title: tk on aqua doesn't know when iconified
comment:
  1. start wish
  2. click on the "-" bubble and the window is iconified to the dock
  3. type "wm state ." to the shell
  4. the answer is "normal" when it should be "iconified"


tkt_uuid: 949792ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: None
resolution: Fixed
title: panedwindow closing error
comment:
  When panedwindow is closed when cursor is over sash,
  error "bad window path name" is generated. It is caused
  by Cursor procedure from panedwindow.tcl. The reason:
  winfo command is invoked after window was destroyed,
  when Cursor is re-scheduled with "after 150" command
  from itself.


tkt_uuid: 950095ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 73. Argv Parsing
priority: 5 Medium
foundin: None
resolution: Fixed
title: CONST-ify fields of Tk_ArgvInfo, (etc.)
comment:
  From casual observation, it seems like most of the fields of 
  Tk_ArgvInfo can be const pointers -- there is no obvious 
  need for Tk to ever overwrite them. Am I wrong, and the 
  code like 
   
  static Tk_ArgvInfo argTable[] = { 
      {"-file", TK_ARGV_STRING, (char *) NULL, (char *) 
  &fileName, 
  "File from which to read commands"}, 
   [...] 
  } 
   
  needs to pass -fwritable-strings to the compiler? 
   
  If I am right, should the typedef be modified? Thanks! 


tkt_uuid: 950121ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 6
foundin: obsolete: 8.4.5
resolution: Fixed
title: Inserting Big Image in Canvas crashes wish (aqua)
comment:
  If an image has more than 4k pixels in height or width then
  trying to add the image to a canvas causes Wish Shell to
  crash.

  This is with Tcl/Tk 8.4.5 on Mac OS X 10.3.3

  Here is a partial dump:
  Exception:  EXC_BAD_ACCESS (0x0001)
  Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x8a0080ff

  Thread 0 Crashed:
  0   com.apple.QD                        0x94d4044c GetPMBaseAddr + 
  0x10
  1   com.apple.QD                        0x94d391e4 
  PixMapToNQDPixMap + 0x24
  2   com.apple.QD                        0x94d3bf7c BitsToPix + 0x160
  3   com.apple.QD                        0x94d39a04 Stretch + 0x134
  4   com.apple.QD                        0x94d4ac4c OneSrcOneDst + 
  0x44
  5   com.apple.QD                        0x94d40538 BitsDevLoop + 0xcc
  6   com.apple.QD                        0x94d39568 CommonBits + 
  0x298
  7   com.apple.QD                        0x94d41200 StdBits + 0x2b4
  8   com.apple.QD                        0x94d394e8 CommonBits + 
  0x218
  9   com.apple.QD                        0x94d43694 CopyBits + 0x36c
  10  com.tcltk.tklibrary                 0x0b079584 TkPutImage + 
  0x290
  11  com.tcltk.tklibrary                 0x0b0443fc DitherInstance + 
  0x6f0
  12  com.tcltk.tklibrary                 0x0b040ab0 
  ImgPhotoConfigureInstance + 0x1d0
  13  com.tcltk.tklibrary                 0x0b040de8 ImgPhotoGet + 
  0x324
  14  com.tcltk.tklibrary                 0x0b039cac Tk_GetImage + 
  0x90
  15  com.tcltk.tklibrary                 0x0b012fa8 ConfigureImage + 
  0xb4
  16  com.tcltk.tklibrary                 0x0b012d64 CreateImage + 
  0xe8
  17  com.tcltk.tklibrary                 0x0b00cb44 CanvasWidgetCmd 
  + 0x9a8


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: 959973ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Fixed
title: wm title bug
comment:
  At placed UTF-8 locale are incorrectly displayed
  non-Latin1 characters in titles of windows (wm title,
  wm iconname, etc.).


tkt_uuid: 960190ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: Fixed
title: MouseWheel binding not OK on Windows
comment:
    Hello,

    When comparing TK versions 8.4.6 and 8.5a1, 
  <MouseWheel> binding has changed, for Windows, from:

  bind Text <MouseWheel> {
          %W yview scroll [expr {- (%D / 120) * 4}] units
      }

  to:

  bind Text <MouseWheel> {
      %W yview scroll [expr {-%D}] pixels
  }

  The result is that one movement in my wheel causes 10 
  lines movements on the text, instead of 3-5 as before. 
  It looks like a bug.

    Regards,

    Ramon Ribó
    ramsan@cimne.upc.es


tkt_uuid: 960391ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 09. [listbox]
priority: 5 Medium
foundin: None
resolution: None
title: Improved binding for listboxes in extended selection mode
comment:
  Improved binding for listboxes in extended selection mode
  =========================================================

  A typical usage of a listbox in extended selection mode
  is the extending of the selection by pressing the
  <Shift> button in combination with hitting the <Up> an
  <Down> arrow keys or pressing the <B1> mouse button.
  The listbox behaviour for these actions is defined in
  the proc tk::ListBoxMotion, which can be found in the
  file listbox.tcl in the Tk library.

  Especially for this specific behaviour, the revised
  proc tk::ListBoxMotion below exhibits considerable
  improvements in execution speed and display handling.

  The revised proc has also been submitted as a patch to
  sourceforge. I post it here to c.l.t for those among
  the newsgroup readers who want to try it in an early stage.


  Sincerely,

  Erik Leunissen
  --------------



  Summary of improvements
  =======================
  a. Changing the selection on various incontiguous
  selected/deselected ranges with <Shift-B1>:
     Reduction of execution time in the order of 25 - 33%
  (1.33 - 1.5 times faster)


  b. Changing (extending/reducing) the selection by a
  single item through <Shift-Up>, <Shift-Down> or
  dragging the mouse one item with <Shift-B1> pressed:
     Reduction of execution time in the order of 50 - 70%
  (2 - 3.5 times faster)


  c. As in b. but for the special case that the action
  doesn't change the selection state of the item under
  the pointer:
     Reduction of execution time in the order of 99 -
  99.3% (100 - 150 times faster)


  With respect to cases b and c:
  Using the standard Tk bindings for listboxes in
  combination with hardware (CPU and video card) that is
  nothing special, an item immediately adjacent to the
  item that to be (de)selected could be seen to flicker
  for a moment. With the revised code, the flicker is gone.

  Erik Leunissen
  ===========


tkt_uuid: 962104ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: None
title: directory creation button
comment:
  Need to add a directory creation button to
  [tk_getSaveFile] on Unix.

  For more details, see
  http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=c94jat%24em1%2405%241%40news.t-online.com


tkt_uuid: 962589ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: Error when handling ^ in some cases
comment:
  This bug has been seenin both 8.4.6 and 8.5 on
  MacOSX (latest AquaBI distros) as well as win98
  (lastest Activestate distros). I assume it affects
  all platforms as it is in generic code.

  The following test code will demonstrate the problem

  gridtest work
  gridtest fail-x
  gridtest fail-omit

  the first time (case work) will not error and will show
  the layout & resize behavior I want *except* that item
  'i' is only there to avoid the bug, I really want empty space
  where 'i' is located - the relevant row  "work" uses:
      grid ^ ^ ^ .i
  to make an explicit empty space case "fail-x" uses:
      grid ^ ^ ^ x
  to make an implicit empty space case 'fail-omit" uses:
      grid ^ ^ ^

  both of the fail cases should give me what I am looking for
  but both complain with "can't use '^', cant find master"

  prod gridtest case {

    catch {eval destroy [winfo children .]}
    foreach w {a b c d e f g h i j k l m n o p q} {
        button .$w -text $w
    }
    grid .a .b .c .d -sticky news -padx 2 -pady 2
    grid .e  - .f .g -sticky news -padx 2 -pady 2
    grid  ^  ^  ^ .h -sticky news -padx 2 -pady 2
    switch $case {
       work {
         grid ^ ^ ^ .i -sticky news -padx 2 -pady 2
       }
       fail-x {
          grid ^ ^ ^ x -sticky news -padx 2 -pady 2
       }
       fail-omit {
           grid ^ ^ ^ -sticky news -padx 2 -pady 2
       }
    }
    grid ^ ^ ^ .j -sticky news -padx 2 -pady 2 
    grid ^ ^ ^ .k -sticky news -padx 2 -pady 2
    grid .l - - - -sticky news -padx 2 -pady 2
    grid .m .n .o .p -sticky news -padx 2 -pady 2
    grid columnconfigure . 1 -weight 1
    grid rowconfigure . 3 -weight 1

  }

  Bruce Hartweg


tkt_uuid: 963020ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.5a1
resolution: Out of Date
title: Problem compiling tk8.5a1
comment:
  # gmake
  gcc -pipe -c -s -O3 -march=i686 -O2 -Wall -Wconversion
  -Wno-implicit-int -fPIC -I/tmp/tk8.5a1/unix
  -I/tmp/tk8.5a1/unix/../generic
  -I/tmp/tk8.5a1/unix/../bitmaps -I/tmp/tcl8.5a1/generic
  -I/usr/X11R6/include -DPACKAGE_NAME=\"\"
  -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
  -DPACKAGE_STRING=\"\" -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_UNISTD_H=1 -DHAVE_LIMITS_H=1
  -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ long
  -DHAVE_STRUCT_STAT64=1 -DHAVE_TYPE_OFF64_T=1
  -DTCL_THREADS=1 -D_REENTRANT=1 -D_THREAD_SAFE=1
  -DPEEK_XCLOSEIM=1 -DTCL_CFG_OPTIMIZED=1
  -DTCL_CFG_DEBUG=1 -DHAVE_SYS_TIME_H=1
  -DTIME_WITH_SYS_TIME=1 -DHAVE_PW_GECOS=1 -DHAVE_XFT=1 
      -DTCL_NO_DEPRECATED -DUSE_TCL_STUBS 
  /tmp/tk8.5a1/unix/../generic/tk3d.c
  In file included from /usr/local/include/tclInt.h:2266,
                   from
  /tmp/tk8.5a1/unix/../generic/../unix/tkUnixPort.h:224,
                   from
  /tmp/tk8.5a1/unix/../generic/tkPort.h:34,
                   from
  /tmp/tk8.5a1/unix/../generic/tkInt.h:27,
                   from
  /tmp/tk8.5a1/unix/../generic/tk3d.h:18,
                   from
  /tmp/tk8.5a1/unix/../generic/tk3d.c:16:
  /usr/local/include/tclIntDecls.h:322: error: parse
  error before '->' token
  /usr/local/include/tclIntDecls.h:326: error: parse
  error before '->' token
  /usr/local/include/tclIntDecls.h:330: error: parse
  error before '->' token
  /usr/local/include/tclIntDecls.h:333: error: parse
  error before '->' token
  /usr/local/include/tclIntDecls.h:337: error: parse
  error before '->' token
  /usr/local/include/tclIntDecls.h:341: error: parse
  error before '->' token
  /usr/local/include/tclIntDecls.h:357: error: parse
  error before '->' token
  /usr/local/include/tclIntDecls.h:360: error: parse
  error before '->' token
  /usr/local/include/tclIntDecls.h:363: error: parse
  error before '->' token
  /usr/local/include/tclIntDecls.h:367: error: parse
  error before '->' token
  /usr/local/include/tclIntDecls.h:370: error: parse
  error before '->' token
  /usr/local/include/tclIntDecls.h:377: error: parse
  error before '->' token
  gmake: *** [tk3d.o] Error 1


tkt_uuid: 965186ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a1
resolution: Fixed
title: TkAqua Scrollbar problem
comment:
  The scrollbar in TKAqua does not behave as expected and is almost 
  unusable. --> See main window of widget demo.

  The scrollbar behaviour has gotten worse from release to release.

  In 8.4.5 the  mouse pointer movement was almost in sync with the 
  scrollbar. Only off by the size of the elevator.

  in other words: to scroll through the entire document the mouse 
  should move a distance equal to the length of the trough MINUS 
  the length of the elevator. apart from that 8.4.5 was fine.

  in 8.4.6 it seems that the scrolbar moves twice as quickly as the 
  mouse pointer.

  in 8.5a1 i cannot see the relationship.

  to fix the bug, 8.4.5 would probably be the best starting-point.

  kind regards,
  uwe

  uwe.kirschner@gmx.net


tkt_uuid: 965398ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: Wish console scroll bug (WinXP)
comment:
  I've just started using ActiveTCL 8.5a2 and have noticed 
  what appears to be an odd scrollbar bug in the Wish 
  console under WinXP SP1A.  The following script 
  illustrates the problem:

  console show
  for {set i 0} {$i < 599} {incr $i} {
      puts $i
  }

  Basically, it places 599 lines of "junk" in the console 
  window.  Once the output is in the console window, if I 
  grab the scrollbar thumbnail and drag it up a ways and 
  then back down to the bottom, the application hangs 
  and the data shown in the console "shimmers" (almost as 
  if it's vibrating).  Ultimately, wish has to be killed.

  For whatever reason, in my testing 599 seems to be the 
  magic breaking point.  Anything less and the console is 
  OK, but 599 or greater and it breaks as described above.

  Also, though I can consistently recreate this, it only 
  seems to happen when dragging the thumbnail (not 
  when pressing the arrows or clicking in the gutter).  
  Also, it only happens when the thumbnail is dragged up 
  and then completely back to the bottom.  Until the 
  bottom is reached, all is fine.

  Jeff


tkt_uuid: 965618ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 31. Cursor Names
priority: 8
foundin: obsolete: 8.4.6
resolution: Fixed
title: -cursor {} undocumented
comment:
  Bug 894550 mentions the following:

  "I believe the {} cursor name
  should restore the cursor to its default state, but I
  haven't found
  where this is stated in the docs (nothing in the
  Tk_GetCursor
  manpage seems to mention the {} cursor). However, several
  applications use this empty cursor name to restore the
  cursor (for
  instance TkChat relies on this behaviour)."

  and gives the following example:

  pack [canvas .c]
  .c create rect 50 50 100 100 -fill red -tags link
  .c bind link <Enter> [list .c configure -cursor hand1]
  .c bind link <Leave> [list .c configure -cursor {}]

  This behaviour, if valid, should be documented.


tkt_uuid: 966845ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: textDisp-16.16 fails
comment:
  Starting with revision 1.41
  of tkTextDisp.c, I see:

  ==== textDisp-16.16 TkTextYviewCmd procedure, "moveto"
  option FAILED
  ==== Contents of test case:

      set count [expr {5 * $bigHeight + 150 * $fixedHeight}]
      set extra [expr {0.04 * double($fixedDiff * 150) /
  double($count)}]
      .t yview moveto [expr {.754 - $extra}]
      .t index @0,0

  ---- Result was:
  151.80
  ---- Result should have been (exact matching):
  151.60
  ==== textDisp-16.16 FAILED


tkt_uuid: 967209ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 23. Option Parsing
priority: 5 Medium
foundin: None
resolution: None
title: TK_OPTION_NULL_OK not fully supported
comment:
  Tk_SetOptions() does not recognize the
  TK_OPTION_NULL_OK flag bit for options of type
  TK_OPTION_INT, TK_OPTION_BOOL, and a few others.

  This causes a bug in the Tile widgets (current CVS
  HEAD), which use  null defaults in several places.  For
  example:

  tlabel .l
  .l configure -width [.l cget -width]
  ==> Error 'expected integer but got ""'

  Workaround possible but this should be fixed in the core.


tkt_uuid: 968725ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: Fixed
title: Patch for anti-aliasing problem with canvas text objects
comment:
  I have discovered a problem with canvas text objects
  that have the same background and selection background
  colors. The anti-aliasing for the rendered font is a
  mixture of the normal text foreground and the
  selected text foreground. Attached to this bug report
  is a sample script showing the problem, a small before
  and after screen cap showing the problem and the fix
  and the patch itself.


tkt_uuid: 969230ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 4
foundin: obsolete: 8.4.6
resolution: Out of Date
title: Mac-Problem with AppleScript in tkMacOSXHIEvents.c
comment:
  I have a problem with the "do script" command in AppleScript, for 
  a TCL/TK application (aMSN)

  Can someone look at this web page? My problem is exactly the 
  same.

  http://frontier-osx.userland.com/discuss/msgReader$1028

  I get  that error when I try to execute an AppleScript 
  "AEDoScriptHandler: invalid script type 'UTXT', must be 'alis' or 
  'TEXT'", with my iTunes Script. I think it can be fixed with the 
  solution #3 on the userland webpage, but I'm not good either to 
  make the fix by my self. The fix should be do in 
  tkMacOSXHLEvents.c
  Thanks :-)

  -- by Edgar C. Rodriguez, Daniel Buenfil and Jérôme Gagnon-Voyer
  --iTunes script to get Path and Name of current track playing, write 
  to a text file, and change the nick in aMSN


  tell application "System Events"
  set iTunes to ((application processes whose (name is equal to 
  "iTunes")) count)
  end tell

  if iTunes is greater than 0 then
  tell application "iTunes"
  --if iTunes is playing, return the artist, the song name and 
  the path (in Unix)
  set newSong to path to application "aMSN" as Unicode text
  set fSong to newSong & "Contents:Resources:Scripts:
  Utils:" & "SongInfo"

  open for access fSong with write permission
  set eof of the fSong to 0
  write "iTunes" & return to fSong starting at eof

  if player state is playing then
  write "Play" & return to fSong starting at eof
  if class of current track is URL track then
  set aSong to name of current track
  set finalpath to 0
  write aSong & return & finalpath & return to fSong 
  starting at eof
  else if class of current track is shared track then
  set aSong to name of current track
  set aArt to artist of current track
  set finalpath to 0
  write aSong & "-" & aArt & return & finalpath & 
  return to fSong starting at eof
  else if class of current track is audio CD track then
  set aSong to name of current track
  set aArt to artist of current track
  set finalpath to 0
  write aSong & "-" & aArt & return & finalpath & 
  return to fSong starting at eof
  else if class of current track is file track then
  set aSong to name of current track as text
  set aArt to artist of current track
  set firstpath to current track's location
  if firstpath is not missing value then
  set finalpath to POSIX path of firstpath
  else
  set finalpath to 0
  end if
  write aSong & "-" & aArt & return to fSong as 
  string starting at eof
  write finalpath & return to fSong starting at eof
  close access fSong
  set fuckingscript to "::MSN::changeName" & 
  aSong as string
  tell application "Wish Shell-soon-final"

  do script fuckingscript as Unicode text
  end tell
  end if


  --if iTunes is paused, return that message
  else if player state is paused then
  write "0" & return to fSong starting at eof
  close access fSong
  --if iTunes is stopped, return that message
  else if player state is stopped then
  write "0" & return to fSong starting at eof
  close access fSong
  end if
  end tell
  --if iTunes is not open
  else
  --i'm not able to do this thing work??!!!
  --set newSong to path to application "aMSN" as Unicode text
  --set fSong to newSong & "Contents:Resources:Scripts:Utils:" 
  & "SongInfo"
  --open for access fSong with write permission
  --set eof of the fSong to 0
  --write "iTunes" & return to fSong starting at eof
  ---write "0" & return to fSong starting at eof
  --close access fSong

  end if


tkt_uuid: 969636ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 06. Canvas Postscript
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: None
title: embedded windows representation offset (horiz.))
comment:
  This also applies to version 8.4.6 (windows version)

  When a postscript file is generated using embedded 
  canvas windows, any embedded window having an offset 
  scrollrange (e.g. {-100, -100, 100 100} will be 
  represented correctly in the vertical direction, but the 
  horizontal direction is still displayed from the absolute 
  zero point.

  An example:
  pack [canvas .c]
  .c create rectangle 1 1 300 300 -fill wheat
  canvas .c1 -width 201 -height 201 -bg white \
             -highlightthickness 0
  .c create window 20 20 -anchor nw -window .c1
  .c1 config -scrollregion {-100 -100 100 100}
  #axis system
  .c1 create line -100 0 100 0
  .c1 create line 0 -100 0 100
  update
  .c postscript -file test.ps


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: 971980ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Accepted
title: Use pkgconfig database to detect Xft
comment:
  I need a way to detect at runtime whether or not Tk was
  built with --enable-xft.

  The TIP #59 pkgconfig database seems like the best way
  to do this.  The attached patch sets the configuration
  key "fontsystem" to "xft" if Tk was built with
  --enable-xft, and leaves it undefined otherwise.  Other
  suggestions for configuration key names welcome.

  (I notice that Tk doesn't currently use
  Tcl_RegisterConfig anywhere else.)


tkt_uuid: 974421ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 28. Utility Functions
priority: 9 Immediate
foundin: obsolete: 8.5a1
resolution: Fixed
title: Documentation bug: Tk_PointToChar
comment:
  The description of Tk_PointToChar in TextLayout(3)
  seems to indicate that the return value is always a
  valid character index (except in the special case of an
  empty string).  It can actually return an index *one
  past* the end of the string (even when the string is
  nonempty).  Manpage should be clarified to reflect this.


tkt_uuid: 974600ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 7 High
foundin: obsolete: 8.5a2
resolution: None
title: Gaps in Line sections
comment:
  Platform: windows (note: bug also appears in v8.4.6)
  When I have created two or more lines on a canvas,  and 
  these lines are "growing" by means of successive insert 
  actions, gaps in line sections may occur under the 
  following conditions (here two lines are supposed):

  - Between any coordinate insert action of both lines the 
  Tk Mainloop must have been active.
  - Coordinates must be non-integer with non-zero 
  fractional part (at least one of the coordinates).
  - Only the LOWEST line (higher y-coordinate) is prone to 
  this behaviour.

  The lines will automatically refresh without gaps when 
  another window will be moved over the lines, regardless 
  whether it is a Tk window or not.

  Attached is a PNG of an example output with two 
  crossing lines. Interestingly: after the line crossing, all is 
  well (but I also have obeyed further gaps in the line 
  which is lowest).

  Here's the test code that results in the attached output:

  #console show
  # test file to show line drawing errors
  canvas .c -width 500 -height 200 -bg white 
  -highlightthickness 0
  #pack [button .b -text start -command {plotlines .c}]
  pack .c

  proc plotlines {w} {
      $w delete line
      set id1 [$w create line 0 0 0 0 -fill red -tags line]
      set id2 [$w create line 0 199 0 199 -fill blue -tags 
  line]
      set n 0
      for {set x 0} {$x < 450} {incr x 2} {
      $w insert $id1 end "$x [expr {$n/5.0}]"
      $w insert $id2 end "$x [expr {199 - ($n/5.0)}]"
      incr n 4
      update
      }
  }

  plotlines .c

  Note: the behaviour has been discovered in a datalogger 
  application where several channels are supplying data 
  via a com port. The data is retrieved event driven using 
  a fileevent setup. The code above lacks this event drive. 
  To achieve the erroneous result, an "update" command 
  is used. The window must be visible during the plotlines 
  call.


tkt_uuid: 975481ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Invalid
title: Bad Path Names For X11 Directory
comment:
  When building tk8.4.6 on Unix, I was met with several 
  error messages stating that various files from the X11 
  directory could not be found. 
   
  I modified the paths for the files that couldn't be found 
  (basically every file with the X11 Directory), in the 
  header files which referenced them (tk.h, Xlib.h, 
  tkIntXlibDecls.h, tkUnixPort.h, and keysym.h) 
  from "X11/filename"  to "../xlib/X11/filename". 
   
  After typing "make" again, it found most of the files, but 
  the tkUnixPort.h file referenced two files that weren't 
  included in the download package (Xpronto.h, and 
  Xresource.h) and thus the package would still 
  not compile.

  Any help with the problem would be greatly appreciated.
  Jason (jdeast@bu.edu)


tkt_uuid: 976928ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: TIP Implementation
resolution: Fixed
title: TIP #204: Virtual events for keyboard traversal
comment:
  Attached patch changes tk::TabToWindow to generate
  TraverseIn and TraverseOut virtual events.  A
  forthcoming TIP describes rationale and motivation.


tkt_uuid: 979101ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 37. [tk_get*File]
priority: 6
foundin: None
resolution: Accepted
title: Env vars in tk_getOpenFile Filename entry?
comment:
  The tk_getOpenFile Filename entry interprets ~/filename 
  as a file in the user's home directory. It would be nice to 
  have environment variables also. eg $HOME/filename.

  Is this something that "should" be done? I suspect 
  windows env vars would be specified in the windows 
  format.

  Would you accept donated code for it? (provided I can 
  find time to do it of course) 


tkt_uuid: 979239ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 9 Immediate
foundin: obsolete: 8.5a2
resolution: Fixed
title: program crash with PNG images
comment:
  Note first off:
  This bug report is cross posted to both the Img
  extension and the Tk toolkit. The reason for this is
  that I cannot determine whether the bug concerns only
  Tk, only Img, or both. A thread in c.l.t around
  23-Jul-2004 did not come up with a conclusion regarding
  the cause.

  Sincerely,

  Erik Leunissen
  ==============

  # The following script exercises problems with PNG images,
  # resulting in a program crash, leaving behind an error
  message
  # of the following format (XXX is a number that varies):
  # 
  #      X Error of failed request:  BadMatch (invalid
  parameter attributes)
  #      Major opcode of failed request:  73 (X_GetImage)
  #      Serial number of failed request:  XXX
  #      Current serial number in output stream:  XXX
  # 
  # - I used:
  #   - Linux (the problems did not occur under Windows)
  #   - Tcl/Tk 8.4.6
  #   - Img1.3
  #
  # - This script uses a label widget, but the crashes occur
  #   also when using buttons instead of labels.
  #
  # - You may need to set the width and height to some
  initial
  #   value, big enough to display the entire image
  #
  # - Choose one of the two crash attempts below
  #

  package require Img
  image create photo png -file ./Error.png
  pack [label .l -width 0 -height 0]


  # PNG CRASH #1
  # First insert the image, then fix size (-width or -height,
  # I show -width only) to a non-zero value too small to
  display
  # the entire image.
  .l configure -image png
  .l configure -width 2 ; # <-- crash occurs here


  # PNG CRASH #2
  # First fix size (width or height) to a non-zero value too
  # small to display the entire image; then insert the image.
  .l configure -width 2
  .l configure -image png ; # <-- crash occurs here

  # EOF


tkt_uuid: 980109ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5a2
resolution: Fixed
title: panic "Bad tag priority being toggled on" using tkChat...
comment:
  Statement apparently causing the error:

  tk::TextSetCursor .txt [tk::TextUpDownLine .txt -1]

  Stack trace:

  NTDLL! DbgBreakPoint address 0x77f7645c
  Tcl_PanicVA(const char * 0x0033de74, char * 
  0x0012e1e4) line 96 + 44 bytes
  Tcl_Panic(const char * 0x0033de74) line 133 + 13 bytes
  TkTextIndexBackChars(const TkText * 0x01b727f0, 
  const TkTextIndex * 0x0012e40c, int 1, TkTextIndex * 
  0x0012e40c, int 3) line 1841 + 16 bytes
  ForwBack(TkText * 0x01b727f0, const char * 
  0x01fd9ac7, TkTextIndex * 0x0012e40c) line 1200 + 21 
  bytes
  GetIndex(Tcl_Interp * 0x008c6e18, TkText * 
  0x01b727f0, const char * 0x01fd9ac0, TkTextIndex * 
  0x0012e40c, int * 0x0012e41c) line 902 + 20 bytes
  TkTextGetIndexFromObj(Tcl_Interp * 0x008c6e18, 
  TkText * 0x01b727f0, Tcl_Obj * 0x01fd9bb0) line 218 + 
  49 bytes
  TextWidgetObjCmd(void * 0x01b727f0, Tcl_Interp * 
  0x008c6e18, int 3, Tcl_Obj * const * 0x008c7764) line 
  1145 + 20 bytes
  TclEvalObjvInternal(Tcl_Interp * 0x008c6e18, int 3, 
  Tcl_Obj * const * 0x008c7764, const char * 
  0x00000000, int 0, int 0) line 3145 + 27 bytes
  TclExecuteByteCode(Tcl_Interp * 0x008c6e18, 
  ByteCode * 0x02331e30) line 1672 + 39 bytes
  TclCompEvalObj(Tcl_Interp * 0x008c6e18, Tcl_Obj * 
  0x00f68630) line 1011 + 13 bytes
  TclObjInterpProc(void * 0x00f69c00, Tcl_Interp * 
  0x008c6e18, int 3, Tcl_Obj * const * 0x0012f66c) line 
  1088 + 19 bytes
  TclEvalObjvInternal(Tcl_Interp * 0x008c6e18, int 3, 
  Tcl_Obj * const * 0x0012f66c, const char * 
  0x0012fbb9, int 26, int 0) line 3145 + 27 bytes
  Tcl_EvalEx(Tcl_Interp * 0x008c6e18, const char * 
  0x0012fbb9, int 26, int 0) line 3644 + 39 bytes
  TclSubstTokens(Tcl_Interp * 0x008c6e18, Tcl_Token * 
  0x0012f7fc, int 1, int * 0x00000000) line 2004 + 31 bytes
  Tcl_EvalEx(Tcl_Interp * 0x008c6e18, const char * 
  0x0012fb9c, int 57, int 0) line 3568 + 31 bytes
  Tcl_Eval(Tcl_Interp * 0x008c6e18, const char * 
  0x0012fb9c) line 3759 + 17 bytes
  Tcl_GlobalEval(Tcl_Interp * 0x008c6e18, const char * 
  0x0012fb9c) line 4911 + 13 bytes
  Tk_BindEvent(Tk_BindingTable_ * 0x008cf048, _XEvent 
  * 0x01fda1d8, Tk_Window_ * 0x01b72ba0, int 0, void * 
  * 0x0012fca8) line 1806 + 25 bytes
  TkBindEventProc(TkWindow * 0x01b72ba0, _XEvent * 
  0x01fda1d8) line 286 + 31 bytes
  Tk_HandleEvent(_XEvent * 0x01fda1d8) line 1064 + 13 
  bytes
  WindowEventProc(Tcl_Event * 0x01fda1d0, int -3) line 
  1446 + 12 bytes
  Tcl_ServiceEvent(int -3) line 624 + 13 bytes
  Tcl_DoOneEvent(int -3) line 929 + 9 bytes
  Tk_MainLoop() line 1627 + 15 bytes
  Tk_MainEx(int 1, char * * 0x008d0060, int (Tcl_Interp *)
  * 0x004010f3 Tcl_AppInit(Tcl_Interp *), Tcl_Interp * 
  0x008c6e18) line 299
  WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 
  0x00000000, char * 0x00133750, int 1) line 129 + 37 
  bytes
  WinMainCRTStartup() line 330 + 54 bytes
  KERNEL32! GetProcessPriorityBoost + 279 bytes

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

  Code around the panic (in "generic/tkTextIndex.c" near 
  line #1841):

  if (tagPtr->elideString != NULL) {
      infoPtr->tagCnts[tagPtr->priority]
  ++;
      if (infoPtr->tagCnts[tagPtr-
  >priority] & 1) {
  infoPtr->tagPtrs[tagPtr-
  >priority] = tagPtr;
      }
      if (tagPtr->priority >= infoPtr-
  >elidePriority) {
  if (segPtr->typePtr == 
  &tkTextToggleOnType) {
      /* 
       * If it is being toggled 
  on, and it has
       * an elide string, it must 
  actually be the
       * current highest 
  priority tag, so this
       * check is redundant:
       */
      if (tagPtr->priority != 
  infoPtr->elidePriority) {
  Tcl_Panic("Bad 
  tag priority being toggled on");
      }

      
      /* 
       * Find previous elide 
  tag, if any (if not
       * then elide will be zero, 
  of course).
       */
      elide = 0;
      while (--infoPtr-
  >elidePriority > 0) {
  if (infoPtr-
  >tagCnts[infoPtr->elidePriority] & 1) {


tkt_uuid: 982248ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: Fixed
title: Hidden Canvas Window Objects
comment:
  Canvas Window objects can be created as hidden, but 
  once visible, their state can not be configured to be 
  hidden again. Here's a sample script (thanks to Slaven 
  Rezic for converting it from Perl to Tcl):

  pack [canvas .c]
  set w [.c create window 50 50 -window [ label .c.label 
  -text Hello ] 
  -state hidden]
  set l [.c create line 30 60 70 60 -state hidden]

  set i 0

  proc repeatproc {} {
      global i w l
      incr i
      if { $i%2 == 0 } {
  .c itemconfigure $w -state hidden
  .c itemconfigure $l -state hidden
      } else {
  .c itemconfigure $w -state normal
  .c itemconfigure $l -state normal
      }
      after 1000 repeatproc
  }

  after 1000 repeatproc


tkt_uuid: 983886ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 21. [panedwindow]
priority: 9 Immediate
foundin: TIP Implementation
resolution: Fixed
title: TIP 177,179 new Panedwindow options
comment:
  Here are the changes for These two tips.  However, this
  patch causes 26 out of 376 panedwindow.test to fail. 
  All the failures are related to moving a sash before
  the window gets mapped.  I'll try and get this sorted
  out, but I thought I'd post this anyway so that others
  can take a look.  Maybe someone can spot the problem.  

  The widget works fine in application.

  -Brian


tkt_uuid: 983920ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: Accepted
title: tkEvent.c refactoring
comment:
  Tk_HandleEvent has been refactored to be easier to
  understand and maintain. 

  During this refactoring a bug was found by Joe English
  that would cause ClientMessage handlers to conflict
  with GenericHandlers in some cases.  

  Code was added to keep the TkDisplay in sync if the
  event involved button 4 or 5.

  No new test failures occur with this patch on my NetBSD
  system.


tkt_uuid: 987107ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 7 High
foundin: obsolete: 8.4.8
resolution: Fixed
title: alpha blending cannot transition transparency properly
comment:
  The alpha blending does not transition from partially
  transparent to fully transparent correctly.

  Currently, it creates an undesired "ghosting" effect
  when using images whose transparency changes gradiently
  from partially to fully transparent.

  It appears that the result pixels near the boundary are
  brighter than they should be (perhaps this is a corner
  case?).

  Dawson and I have come up with test images and a
  special test script that fully illustrates the problem
  (and the desired output).


tkt_uuid: 987169ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 9 Immediate
foundin: obsolete: 8.5a1
resolution: Fixed
title: missing <Destroy> binding
comment:
  Situation: 
   
  wish 
  % toplevel .t 
  tk_messageBox -parent .t 
   
  -> now press on the close button of ".t" 
   
  -> ".t" will be destroyed and messageBox 
  of course too, since it is a descendant of ".t" 
   
  -> the wish will now block indefinatly in the 
  "vwait ::tk::Priv(button)" of the (now vanished) 
  messageBox. 
   
  I think you should consider to incluse a binding  
  on the <Destroy> event somewhere in msgbox.tcl 
  script. 
   
  For example like this (after # 6.): 
   
   
  bind $w <Destroy> "if {!\[info exists 
  ::tk::Priv(button)\]} { 
      [$w.$data(-default) cget -command] 
      }" 
   
   
  This set the variable (vwait waits for) with whatever 
  was configured to be the default.  
   
  Note: You have additionally to make shure, that 
  the variable is unset one you invoke the messageBox. 
   
  I changed therefore (after # 1.): 
      catch {destroy $w} 
   
  into: 
   
      destroy $w 
      unset -nocomplain ::tk::Priv(button) 
   
  The catch is not needed anymore. 
   
   
  Note also: 
   
  To make the whole thing reentrant, you should 
  rename this variable info something, that includes 
  the widgetname like ::tk::Priv($w,button) 
   
   


tkt_uuid: 991849ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 48. Geometry Management
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: None
title: removal/optimization of scrollbar events?
comment:
  While developing my application, I noticed that in some
  cases, I got scroll commands invocations with
  exceedingly small first and last range.
  For example:

  proc echo {args} {
    foreach argument $args {puts -nonewline "$argument "}
    puts {}
  }
  .canvas configure -xscrollcommand echo

  would, in some cases, give:
  0 0.00201613

  Since I use this type of code to automatically manage
  scrollbars (displayed only when needed), I end up with
  scrollbars displayed when they should not, as the event
  above implies that a scrollbar is needed (last - first
  < 1).

  At the time these events happen, and after looking at
  the 8.4.6 tkCanvas.c source code, [winfo width .canvas]
  = 1, which means that these events are not really
  valid, in the sense that the canvas is not really
  "displayed" yet (my interpretation).

  I traced the problem (if that is indeed one) using
  printf() calls, in ConfigureCanvas():

    ...
      printf("canvasPtr->xOrigin = %d,
  Tk_Width(canvasPtr->tkwin) = %d\n",  
  canvasPtr->xOrigin, Tk_Width(canvasPtr->tkwin));
      Tk_CanvasEventuallyRedraw((Tk_Canvas) canvasPtr,
        canvasPtr->xOrigin, canvasPtr->yOrigin,
        canvasPtr->xOrigin + Tk_Width(canvasPtr->tkwin),
        canvasPtr->yOrigin + Tk_Height(canvasPtr->tkwin));
      return TCL_OK;
    }

  which gives:

    canvasPtr->xOrigin = 0, Tk_Width(canvasPtr->tkwin) = 1

  followed by, in Tk_CanvasEventuallyRedraw():

    ...
    if (!(canvasPtr->flags & REDRAW_PENDING)) {
      printf("canvasPtr->redrawX1 = %d,
  canvasPtr->redrawX2 = %d\n", canvasPtr->redrawX1,
  canvasPtr->redrawX2);
      Tcl_DoWhenIdle(DisplayCanvas, (ClientData) canvasPtr);
      canvasPtr->flags |= REDRAW_PENDING;
    }
  }

  which gives:

    canvasPtr->redrawX1 = 0, canvasPtr->redrawX2 = 1

  followed by the invocation of the X scroll command with
  first = 0, last = 0.00201613, as described before.

  Now there are quite many "invalid" events of this sort,
  which invoke commands at the Tcl level. Filtering these
  out at the C code level (when [winfo width/height] = 1,
  as I now do at the Tcl level in my automatic scrollbar
  code) would possibly improve Tk display performance and
  remove some display errors.

  What do you think? 

  Best regards,

  Jean-Luc


tkt_uuid: 994629ffffffffffffffffffffffffffffffffff
type: Support
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
title: tip 169, peer text widgets
comment:
  The attached patch implements making the 'sel' tag
  widget-specific (part of tip169).  

  Apparently more of this tip is available here:

  A reference implementation based on Tcl 8.4.5 can be
  found at ftp://ftp.model.com/pub/tcl/textpeer845.tgz
  This archive contains modified tkText*.[ch] files that
  implement the [$w peer create] and [$w peer names]
  methods described above.

  So the major remaining component is to make the
  pixel-height calculations widget specific.

  Contributions encouraged.


tkt_uuid: 995291ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: ctrl+v problem
comment:
  On my linux box ctrl+v fires correctly the Paste
  binding (using the script bellow) but paste nothing in
  the text widget. ctrl+y fires the Paste binding too and
  paste the clipboard buffer in the text widget.

   #!/usr/bin/env wish
   package require Tk
   pack [text .t]
   bind .t <<Copy>> { puts copy }
   bind .t <<Cut>> { puts cut }
   bind .t <<Paste>> { puts paste }


tkt_uuid: 996070ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: Invalid
title: events to previously unmapped windows are silently dropped
comment:
  code snippet to illustrate the issue:

  bind <<test>> "puts hi!"

  proc blah {} {
  toplevel .test
  event generate .test <<test>>
  }

  % blah
  %

  an event to a window that truly does not exist will
  throw an error:

  bad window path name ".test"
      while executing
  "event generate .test <<test>>"


  i think ideally a case should be added to [event] to
  make the window "exist" or somehow fire the event
  anyways. but im not aware of all the internal things
  going on here so that is just a suggestion. at the very
  least i believe it should be documented that your
  events will be lost.


tkt_uuid: 997689ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: [wm attributes] patch for Mac OS X
comment:
  This patch fixes up [wm attributes] handling on Mac OS X. 
  Specifically, it updates to use newer APIs (both Tcl and Carbon), 
  implements read for the -titlepath option and correctly implements 
  individual option introspection.


tkt_uuid: 998125ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 08. [(label)frame] and [toplevel]
priority: 8
foundin: TIP Implementation
resolution: Fixed
title: Tip #125 Implementation
comment:
  Attached is a patch to implement Tip #125 [wm manage]
  and [wm forget] commands.  The patch includes Unix and
  Windows implementations as well as a partial
  implementation for MacOSX.  For Aqua, only the button
  and menubutton widgets may be placed in a [wm manage]'d
  frame.  To complete the implementation, the
  TK_URBAN_RENEWAL flag must be recognized and handled by
  all the intrinsic Tk widgets.  See the patch for details.

  You'll note that this patch implments an alternative
  approach to the original [wm topleve] proposal.  See
  the updated Tip for details of this change.


tkt_uuid: 9de9e8faa694d377d58e335fab0d3fdd94d99a52
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
severity: Severe
foundin: 8.6.0
private_contact: c5ad054236f64b5e8623bb587700371079b387a5
resolution: Duplicate
title: Wish crashes with ‘num matched toplevel windows does not equal num children’
comment:
  An error occurs in AlphaTk on MacOS X Intel (I'm trying to make it work again for me):

  num matched toplevel windows does not equal num children
  /usr/local/bin/wish8.6: line 2: 95412 Abort trap: 6           "$(dirname $0)/../../../Library/Frameworks/Tk.framework/Versions/8.6/Resources/Wish.app/Contents/MacOS/Wish" "$@"

  Apparently, it occurs when I change from one window to another but I cannot narrow it down when it exactly appears.

  tcl_platform(byteOrder)     = littleEndian
  tcl_platform(machine)       = x86_64
  tcl_platform(os)            = Darwin
  tcl_platform(osVersion)     = 12.5.0
  tcl_platform(pathSeparator) = :
  tcl_platform(platform)      = unix
  tcl_platform(pointerSize)   = 8
  tcl_platform(threaded)      = 1
  tcl_platform(wordSize)      = 8


tkt_uuid: b7445265123a5ebb88127b15f00e6436cc220788
type: Bug
status: Pending
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
severity: Minor
foundin: 8.6 trunk
private_contact: 591ec66e585a48f215946ef7f9b0cf43417a383e
resolution: Wont Fix
title: ::ttk::spinbox doesn't initialize value of box
comment:
  [spinbox .path/to/widget -from 0 -to 100 ...] causes the created spinbox to have the value 0, but the value is empty for the analagous [::ttk::spinbox].


tkt_uuid: c597acdab39212f2b5557e69e38eb3191f4a5927
type: Bug
status: Closed
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
severity: Important
foundin: 8.6
private_contact: df68c27e6baf9e5e5ff7eebbbbe353162a6be54c
resolution: Fixed
title: ttk::progressbar stop command doesn't work in tracing function
comment:
  Test-case:

  -----
  ttk::progressbar .progbar -variable ::var -mode indeterminate

  proc tracer {varname args} {
      upvar #0 $varname var
      puts "var value: $var"

      # Note: call has no effect
      .progbar stop
  }

  trace add variable ::var write "tracer ::var"

  .progbar start
  pack .progbar
  -----

  Note how ".progbar stop" is being called in the tracing function, but it has no effect on the progress bar, it still continues to run. Calling "progbar stop" from the outside (e.g. after ".progbar start") does work however.

  I've filed this as Important since I use a tracing function for a binding to Tk to another language.

  I'm on Windows 7 x64, using Tk 8.6.


tkt_uuid: d1d4286ddaad47daef8c187cc5596f7e34b238d2
type: Bug
status: Open
subsystem: 16. [scrollbar]
priority: 5 Medium
severity: Minor
foundin: 8.6
private_contact: df68c27e6baf9e5e5ff7eebbbbe353162a6be54c
resolution: None
title: ttk::scrollbar behaves differently than tk::scrollbar on win32
comment:
  Here's a small test-case showing the behavior of 'tk::scrollbar':

  -----
  package require Tk

  wm geometry . 300x200+50+50

  tk::listbox .listbox -yscrollcommand ".scrollbar set" -height 5
  tk::scrollbar .scrollbar -command ".listbox yview" -orient vertical

  grid .listbox -column 0 -row 0 -sticky nwes
  grid .scrollbar -column 1 -row 0 -sticky ns
  grid columnconfigure . 0 -weight 1
  grid rowconfigure . 0 -weight 1

  for {set i 0} {$i<100} {incr i} {
     .listbox insert end "Line $i of 100"
  }
  -----

  Some notes:

  - If using the left mouse button you click and hold below the scrollbar thumb, the scrollbar will move page by page until it reaches the location of the mouse cursor.

  - The background area below the thumb will change color (usually into black).

  But with the themed scrollbar (ttk::scrollbar), the behavior is different:

  - When you click and hold below the scrollbar thumb, the scrollbar will move all the way to the bottom, it won't stop to the cursor position.

  - The background area below the thumb does not change color.

  It seems like ttk::scrollbar has the same issues as e.g. GTK's scrollbar on win32, it doesn't seem to act natively.


tkt_uuid: e48513468334665015dfd3aca89c2ffb9458fa9b
type: Bug
status: Open
subsystem: 99. Other
priority: 5 Medium
severity: Minor
resolution: None
title: messageBox documentation for -message likely wrong
comment:
  On this page: http://www.tcl.tk/man/tcl8.6/TkCmd/messageBox.htm

  For the -message option it says:

  -message string
      Specifies the message to display in this message box. This option is ignored on Mac OS X, where platform guidelines forbid the use of a title on this kind of dialog. 

  The OSX-specific text refers to a "title", maybe this part of the docs should have been part of the -title docs?


