# ticket

tkt_uuid: 414033ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.2.1
resolution: Fixed
title: jisx0201 encoding
comment:
  A simple typo prevents tk from choosing a font with
  jis0201 encoding to display Japanese strings.

  The typo appears to still exist in the head revision of
  tkUnixFont.c

  the following script should show the problem:
  button .b -text \uFF80
  pack .b


tkt_uuid: 414173ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: Fixed
title: SafeTk with -use crashes wish
comment:
  Using safeTk with -use crashes Wish on Windows 95 and
  98.  Works fine on Linux.
  The problem does not occur when -use is not used.

  The following script exercises the bug.

  pack [frame .f]
  wm geom . 300x30
  pack .f -fill both -expand y
  set slave [safe::interpCreate]
  safe::loadTk $slave -use .f


  The seg fault occurs in Tk_GeometryRequest,
  where winPtr is NULL.  It appears that this is from
  containerPtr->parentPtr referenced in
  EmbedGeometryRequest which is NULL.  Perhaps
  window isn't mapped???


  (gdb) bt
  #0  0x556e00 in Tk_GeometryRequest (tkwin=0x0,
  reqWidth=258, reqHeight=489)
      at ./../generic/tkGeometry.c:154
  #1  0x58543c in EmbedGeometryRequest
  (containerPtr=0x5b1e6c8, width=258,
      height=489) at tkWinEmbed.c:444
  #2  0x585400 in TkWinEmbeddedEventProc (hwnd=0xc74,
  message=1025, wParam=258,
      lParam=489) at tkWinEmbed.c:400
  #3  0x542ce1 in TkWinChildProc (hwnd=0xc74,
  message=1025, wParam=258,
      lParam=489) at tkWinX.c:550
  #4  0xbff958f8 in _size_of_stack_reserve__ ()
  #5  0x54b621 in Tk_HandleEvent (eventPtr=0x34a04d0)
      at ./../generic/tkEvent.c:849
  #6  0x54bb63 in WindowEventProc (evPtr=0x34a04c8,
  flags=-1)
      at ./../generic/tkEvent.c:1199
  #7  0x6ae359 in Tcl_ServiceEvent (flags=-1) at
  ./../generic/tclNotify.c:607
  #8  0x6ae610 in Tcl_DoOneEvent (flags=-1) at
  ./../generic/tclNotify.c:846
  #9  0x581408 in Tk_UpdateObjCmd (clientData=0xb308d0,
  interp=0xb280c4, objc=1,
      objv=0xb3815c) at ./../generic/tkCmds.c:949
  #10 0x67e909 in TclExecuteByteCode (interp=0xb280c4,
  codePtr=0x5a8281c)
      at ./../generic/tclExecute.c:858
  #11 0x647d84 in Tcl_EvalObjEx (interp=0xb280c4,
  objPtr=0x3423a00, flags=0)
      at ./../generic/tclBasic.c:2837
  #12 0x67a7c3 in TclObjInterpProc (clientData=0x3458ae8,
  interp=0xb280c4,
      objc=5, objv=0xb38148) at
  ./../generic/tclProc.c:1014
  ---Type <return> to continue, or q <return> to quit---


tkt_uuid: 415166ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
severity: Minor
foundin: None
resolution: Works For Me
title: W98: wish hangs after panic
comment:
  (see also tcl-bug #406709, already closed)

  Apparently wish hangs after a panic: "The error causes
  Wish to hang, and CPU and memory usage goes up to near
  maximum. The wish and console windows remain visible
  but do not redraw if you cover and uncover them with
  another app (you are left with white  window-shaped
  objects). The only solution is to reboot the computer.
  "

  The problem has been reported on Win98SE, apparently
  happens also in Win98SP2.

  The scriptlet 
      while 1 {puts [break]}
  should exercise the bug up to tcl8.4a2 (but *not* in
  current sources)- it causes a panic. tclsh apparently
  exits cleanly, but wish hangs as reported.

  The first report included the script
      proc createByteCodeBug {} { 
          set path [frame .frame]; 

          entry $path.command; 
          text $path.text; 

          pack $path.command -side bottom -fill x -expand
  1; 
          pack $path.text -side top -fill both -expand 1; 

          $path.command configure -state disabled; 
          $path.text configure -state normal; 
          focus $path.text; 
          foreach {dir equiv} [list Up k Down j Left h
  Right l] { 
              bind $path.text <Key-$dir> {} 
              bind $path.text <Key-$equiv> [concat [bind
  Text <Key-$dir>]; break]; 
           } 
      } 

      createByteCodeBug


tkt_uuid: 415271ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Fixed
title: Requesting for MS accessibility feature
comment:
   Hi,

   I have been exchanging few emails with Jeff Hobbs and he suggested me to
   report to track this item for future release of Tcl/Tk.  Windows 2000 ships 
   with a magnifier utility (Program Menu->Accessories->Accessibility->Magnifier) 
   which allows for user can track (or focus) traversing GUI app windows via 
   Tab-key from keyboard and any text being entered through the keyboard.
   According Microsoft Windows 2000 logo certification requirement list, this is 
   an required functionality to be supported by Windows GUI application.

   Following URL explains more details about Windows 2000 logo certification:

     http://msdn.microsoft.com/certification/download.asp  
   
   In Section 3.4 of Server specification (Expose the location of the keyboard
   focus) explains which Win32 APIs can be used to add the magnifier support
   in the GUI application.   

   We (in NCR Corporation) have a Tcl/Tk application as part of Teradata RDBMS
   server package and it was failing this requirement.     Because Windows logo
   certifcation is somewhat new in Tcl/Tk community, it is no surprise that MS
   accessibility feature is not implemented in Tcl/Tk.  Actually the latest version
   of Java 1.3 does not support MS accessibility either.

   Could you please consider implementing MS accessibility feature into the
   Tk core in the future release ?   Note that this request only specific Windows
   platform only.
   
   Thanks,

   Moo Kim
   


tkt_uuid: 415757ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 71. Error Handling
priority: 4
foundin: obsolete: 8.3.3
resolution: Fixed
title: Incorrect [bgerror] documentation
comment:
  bgerror(n) distributed with Tk 8.3.3 describes
  a user-configurable button (via the option database)
  in Tk's [bgerror] implementation.

  This feature is not available in Tk 8.3.  It first
  appears in Tk 8.4.


tkt_uuid: 415788ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: Works For Me
title: change to bold brks hilighting
comment:
  Changing the existing font in an entry widget to bold (which changed character widths) will cause 
  the widget to behave incorrectly for highlighting words. Similar defect applies to entry widget.
  This defect was reported around july 2000 but somehow seems to have gotten lost.

  Tested against 8.4a2

  # 21Jul00RT - if a bold font is specified to the
  # existing font then cursor position is calculated wrong!

  package require Tk
  entry .e -width 40

  # Add bold attribute to existing font
  # e.g: .e config -font {{MS Sans Serif} 8 bold}
  .e configure -font [concat [.e cget -font] bold]

  .e insert end "                    word"

  pack .e

  # now put cursor at start of word1 and drag to select
  # Widget will begin to select spaces


tkt_uuid: 415790ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: Invalid
title: tag binding <Key> fails on non-mouse mov
comment:
  Setting a tag binding on <Key> only seems to fire if the
  tagged text was entered by a mouse click. Likewise, if the
  tagged text is exited by cursor keys (instead of mouse) then the
  widget keeps fireing the binding even though it's clearly
  not appropriate.

  #  12Apr01 Roy Terry
  # Shows defects in detecting tag binding. Based on varying ways
  # of getting the cursor into the tagged area, sometimes it fires
  # and sometimes it doesn't. If it starts firing (in red area) then
  # using right cursor to blue area will have it *still* firing.
  # IOW, the tags binding only seems to work properly if the tagged area
  # is entered or exited via a mouse click. Is this right? 

  set t [toplevel .top]
  set txt [text .top.txt]
  pack $txt
  $txt tag config tag1 -background red
  $txt tag config tag2 -background blue
  $txt insert 1.0 "I am tag1" tag1 "This is tag2" tag2
  $txt tag bind tag1 <Key> bell


tkt_uuid: 415906ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Invalid
title: tk make functions fails
comment:
  I'm having trouble getting the tk install completed 
  because the make step keeps blowing up with errors 
  1506-046 errors for any statements defined as Boolean 
  in the tk.h and tkdecl.h files.  I'm in a unix 
  environment and we use ibm C.  All of the statements 
  with syntax problems are part of a stucture 
  statement.  Can someone suggest a way around this 
  problem?


tkt_uuid: 418653ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 72. Atoms
priority: 7 High
foundin: None
resolution: Fixed
title: UTF8_STRING cut&paste selection target
comment:
  Even though Tk uses UTF-8 internally, there is
  currently no support for UTF-8 cut & paste selections.

  X.Org has just officially registered the new atom
  UTF8_STRING both as a property type and as a selection
  target. It has already been used for quite some time in
  xterm and other UTF-8 aware X11 applications, and it
  would be good if Tk could follow.

  See

  http://www.cl.cam.ac.uk/~mgk25/ucs/xorg.html
  http://www.cl.cam.ac.uk/~mgk25/unicode.html#x11

  for the extension of the ICCCM to support UTF8_STRING
  in X11R6.6.1. It is very straight forward.

  You can implement this easily also on any older X11
  release.

  It would be extremely useful if we could cut and paste
  UTF-8 strings between Tk widgets and xterm.


tkt_uuid: 418664ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Fixed
title: grid config rejects initial "x" and "^"
comment:
  According to grid(n):

    grid configure slave ?slave ...? ?options?
      The arguments consist of the names of one or more
      slave windows followed by pairs of arguments that
      specify how to manage the slaves.  The characters
      -, x and ^, can be specified instead of a window
      name to alter the default location of a slave, as
      described in the ``RELATIVE  PLACEMENT'' section,
      below.

  However:

      % grid configure x [label .l]
      bad argument "x": must be name of window

  Furthermore this is a bizarre inconsistency with
  the "shortcut" form of [grid configure]:

      % grid x [label .l]
      # No error!

  I attach a patch that corrects the bug and clarifies
  the documentation.


tkt_uuid: 418943ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Accepted
title: Don't subst STUB_LIB_FILE for tk.
comment:
  This is in ref to Tcl patch  This will fix
  the problem fixed by 418432. in Tcl for Tk.
  Ok to check in?


tkt_uuid: 420510ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 31. Cursor Names
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Fixed
title: Win32 -cursor doesn't handle fg/bg color
comment:
  Windows parsing of the -cursor option barfs if you specify a foreground and/or background color.  For example:
      . config -cursor {circle red black}
  works fine on Unix platforms, but results in the error message
      bad cursor spec "circle red black"
  on Windows.  It looks like TkGetCursorByName isn't breaking up the string parameter before trying to find the cursor.

  Correct behavior would be to handle the cursor as it is in the Unix world.

  An acceptable alternative would be to ignore the foreground and background colors under Windows.  This means the same source will run on both Windows and Unix, and behave correctly on Unix.

  I haven't checked this on Mac.


tkt_uuid: 420861ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 08. [(label)frame] and [toplevel]
priority: 5 Medium
foundin: TIP Implementation
resolution: None
title: Tip#18 (labelframe) changes, part 1.
comment:
  This patch is part of the work with TIP#18, adding a labelframe widget.
  It consists of two main parts.

  The first is a general polish of the frame, the biggest change being an upgrade from the old 
  TK_CONFIG style option management to the newer TK_OPTION style. It also fixes a potential mem 
  leak.

  The second part implements the changes to geometry management, as described in TIP#18.

  These changes are the foundation on which the changes doing the actual labelframe stand so I 
  would appreciate some feedback on these parts now while finishing the rest of the work.

  The patch is made against the CVS head on 2 May 2001.


tkt_uuid: 422256ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 53. [selection]
priority: 1 Zero
foundin: None
resolution: Fixed
title: Minor doc updates
comment:
  I added a comment in the selection man page about the
  existance of
  the clipboard command, and put see-alsos in both.


tkt_uuid: 422411ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: Tab behaviour inconsistent
comment:
  Insertion of \t in a text widget has two different kinds of behaviour, depending on how the tab stops were set.

  a) With the default 8 characters per tab, the effect of inserting \t is to move the insertion point to the next tab stop to the right.

  b) If you set (with -tabs) other tab stops, the effect of the nth \t in a line is to attempt to position the insertion pont at the nth tab stop. If this is not possible (insertion point already to right of nth stop) then \t inserts a single space.

  The behaviour of tabs should be consistent, regardles of how tab stops were set. My personal preference would be for behaviour a), which I think is what most people would expect.

  Illustrative script file attached.


tkt_uuid: 427278ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Fixed
title: Static library fonts need TkWinXInit
comment:
  The full meal deal is a newsgroup entry by Eirik 
  Rensvik dated 23 May 2001, titled "Font problem when 
  wrapping C - Tcl/Tk," and my response.  

  When dynamic Tcl and Tk libraries are used with a C 
  program, DllMain calls TkWinXInit, which initializes 
  the platform id.  Since the platform id is 
  initialized, when TkpFontPkgInit is called, it sets 
  the system encoding correctly.  Since the system 
  encoding is correctly set, when FamilyExists is 
  called, it encodes the font family name correctly and 
  finds the font family it's looking for.  

  When static libraries are used with a C program, 
  DllMain is of course not called, and TkWinXInit isn't 
  called until TkpFontPkgInit has already run.  
  TkpFontPkgInit fails, and so FamilyExists fails.  

  We are in luck.  There is a simple script that can be 
  used to diagnose whether this problem exists.  

  set fontlist [lsort [font families]]
  foreach name $fontlist {
      puts "font $name"
  }

  yields

  font A
  font A
  font A
    :

  if the problem exists, and 

  font Arial
  font Arial Baltic
  font Arial Black
          :

  if it doesn't.  

  I solved the problem by calling TkWinXInit myself 
  before I called Tcl_Init or any other Tcl or Tk 
  function.  I don't know how you want to organize the 
  code.  Maybe put it early in Initialize?  (And leave 
  it in Tkp_Init, or take it out?)  

  Hey.  SourceForge doesn't have a field on the bug form 
  for platform.  I am working on Windows NT.  Well, 
  really Windows 2000.  

  Hope this helps.  

          Rick


tkt_uuid: 428446ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3.1
resolution: Out of Date
title: Core dump on tk_getOpenFile
comment:
  The following script will demonstrate the problem:

  set DISPLAY "[info hostname]:0.0"
  toplevel .foo -screen $DISPLAY
  set mb [menu .foo.menu]
  .foo configure -menu $mb
  tk_getOpenFile

  Here is a wish transcript that demonstrates it on my platform:

  % parray tcl_platform
  tcl_platform(byteOrder) = bigEndian
  tcl_platform(machine)   = sun4m
  tcl_platform(os)        = SunOS
  tcl_platform(osVersion) = 5.6
  tcl_platform(platform)  = unix
  tcl_platform(user)      = sealj
  % puts $tcl_patchLevel
  8.3.1
  % puts $tk_patchLevel
  8.3.1
  % toplevel .foo -screen "[info hostname]:0.0"
  .foo
  % .foo configure -menu [menu .foo.menu]
  % tk_getOpenFile
  Tk_Get3DBorderFromObj called with non-existent border!
  Abort (core dumped)

  The crash does not always occur instantaneously, sometimes it doesn't occur until you either move 
  the tk_getOpenFile window or the mouse enters another window. The problem does not occur if

  * You use the original "." toplevel, or
  * You omit the -screen argument to the new toplevel, or
  * You don't configure the new toplevel with a -menu.

  If you call tk_getOpenFile before doing those things, then sometimes it will still work afterward 
  without crashing.


tkt_uuid: 428784ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Fix for bug #226357 Overlapping with Pol
comment:
  Remove test for polygon fill that was causing
  problems and provided no benefit.

  Test case (good result):

  $ wish8.4
  % pack [canvas .c]
  % .c create poly 30 30 30 90 90 90 90 30 -fill ""
  -outline black
  1
  % .c find over 45 45 45 45
  1
  % .c find over 0 0 0 0
  % info patch
  8.4a3
  % 


tkt_uuid: 430116ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 57. [option]
priority: 7 High
foundin: obsolete: 8.4a3
resolution: Invalid
title: [option get] behavior change
comment:
  The following script works in Tcl/Tk 8.0 and Tcl/Tk 8.2 but fails in Tcl/Tk 8.4:

   proc jnl_entryState { e state } {
       switch -- $state {
           normal {
               $e configure \
                      -foreground [option get $e *Entry.Foreground Foreground] \
                      -background [option get $e *Entry.Background Background]
           }
           disabled {
               $e configure \
               -foreground \
               [option get $e *Entry.DisabledForeground DisabledForeground] \
               -background \
               [option get $e *Entry.DisabledBackground DisabledBackground]
           }
       }
       # switch
   }
   # jnl_entryState


   wm withdraw .
   toplevel .foo -class Foo


   set class [winfo class [winfo toplevel .foo]]

   option add  *${class}*Entry.Foreground grey widgetDefault
   option add  *${class}*Entry.DisabledForeground green widgetDefault

   option add  *${class}*Entry.Background white widgetDefault
   option add  *${class}*Entry.DisabledBackground blue widgetDefault

   entry .foo.e
   pack .foo.e

   button .foo.exit -text Done -command exit
   pack .foo.exit

   jnl_entryState .foo.e disabled

  In Tcl/Tk 8.4 it produces:

   Error in startup script: unknown color name ""
       (processing "-foreground" option)
       invoked from within
   "$e configure  -foreground  [option get $e *Entry.DisabledForeground DisabledForeground]   
  -background  [option get $e *Entry.DisabledBackground Disable..."
       ("disabled" arm line 2)
       invoked from within
   "switch -- $state {
            normal {
                $e configure  -foreground [option get $e *Entry.Foreground Foreground]  -background  
  [option get $e *..."
       (procedure "jnl_entryState" line 2)
       invoked from within
   "jnl_entryState .foo.e disabled
   "
       (file "testOption.tcl" line 39)


tkt_uuid: 431229ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Postponed
title: Can't build Tk on HP-UX 10.2
comment:
  gcc -pipe -c -O -Wall -Wconversion -Wno-implicit-int -fPIC
  -I/pti/tests/5/nelson/prdtcl84/tcl/v8.4/hp10/tk/unix
  -I/pti/tests/5/nelson/prdtcl84/tcl/v8.4/hp10/tk/unix/../generic
  -I/pti/tests/5/nelson/prdtcl84/tcl/v8.4/hp10/tk/unix/../bitmaps
  -I/pti/tests/5/nelson/prdtcl84/tcl/v8.4/hp10/tcl/generic
  -I/usr/local/X11R6/include -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1
  -DNO_FD_SET=1 -DHAVE_SYS_TIME_H=1      -DTCL_NO_DEPRECATED  

  -DTK_LIBRARY=\"/pti/tests/5/nelson/prdtcl84/tcl/v8.4/hp10/tk/unix/../../../INSTALL/lib/tk8.4\"
  \
      /pti/tests/5/nelson/prdtcl84/tcl/v8.4/hp10/tk/unix/tkUnixInit.c
  In file included from
  /pti/tests/5/nelson/prdtcl84/tcl/v8.4/hp10/tk/unix/../generic/tkPort.h:32,
                   from
  /pti/tests/5/nelson/prdtcl84/tcl/v8.4/hp10/tk/unix/../generic/tkInt.h:27,
                   from
  /pti/tests/5/nelson/prdtcl84/tcl/v8.4/hp10/tk/unix/tkUnixInit.c:15:

  /pti/tests/5/nelson/prdtcl84/tcl/v8.4/hp10/tk/unix/../generic/../unix/tkUnixPort.h:94:
  conflicting types for `fd_mask'
  /usr/include/sys/types.h:413: previous declaration of `fd_mask'
  gnumake: *** [tkUnixInit.o] Error 1


tkt_uuid: 432093ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: None
resolution: Fixed
title: listbox-23.5 test fails color darkblue
comment:
  On our HP/UX systems, test "listbox-23.5 ConfigureListboxItem, multiple calls"
  fails with the message 'unknown color name "darkblue"'  I checked the listing
  of color names at http://tcl.activestate.com/man/tcl8.3.2/TkCmd/colors.htm
  and found "dark blue" and "DarkBlue".

  Since this test really  isn't trying to verify specific colors on a system, can
  we change the color choice for "darkblue" to a more common named color?


tkt_uuid: 432104ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 30. Color Names
priority: 5 Medium
foundin: None
resolution: Fixed
title: Blue colors documented as RGB 0 0 0
comment:
  In the colors documentation man pages at 
  http://tcl.activestate.com/man/tcl8.3.2/TkCmd/colors.htm and
  http://tcl.activestate.com/man/tcl8.4/TkCmd/colors.htm

  all these colors are documented as having RGB values 0 0 0:

  blue, blue1, blue2, blue4, dark blue, DarkBlue, medium blue, MediumBlue, 
  navy, navy blue, NavyBlue

  When I query my X server, I get these values:


    0   0 255             blue
    0   0 255             blue1
    0   0 238             blue2
    0   0 205             blue3
    0   0 139             blue4
   50  50 204             medium blue
   50  50 204             mediumblue
   35  35 117             navy blue
   35  35 117             navyblue

  but I don't get a value for darkblue.  Is that really a color?  I don't see it
  in my /usr/lib/X11/rgb.txt.


tkt_uuid: 432435ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 8
foundin: None
resolution: Fixed
title: Tk_InitConsoleChannels needs docs
comment:
  The public Tk function, Tk_InitConsoleChannels()
  has no documentation.

  When the documentation is written, it should make
  it clear that Tk_InitConsoleChannels() must be called
  early in a program -- before any Tcl_Channel operations
  have a chance to take place.

  Otherwise, the failure of Tk_InitConsoleChannels()
  to Tcl_RegisterChannel() the console channels
  -- it can't, it has no interp to work with --
  and the lack of auto-registration of the Tcl
  standard channels to make up for it -- because the
  previous Tcl_Channel operations already initialized
  the Tcl standard channels to the system defaults --
  will cause nasty errors like

   "can not find channel named "stderr""

  See attached demo.c for explanation of how to
  properly use Tcl_SetStdChannel, and why
  Tk_InitConsoleChannels() can't do that, so must
  be called early instead.


tkt_uuid: 432603ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 1 Zero
foundin: obsolete: 8.4a3
resolution: Invalid
title: warnings during compile on Solaris
comment:
  flare: [5] > uname -a
  SunOS flare.home.tmh 5.8 Generic_108528-08 sun4m sparc
  SUNW,SPARCstation-5
  flare: [6] > psrinfo -v
  Status of processor 0 as of: 06/12/01 19:06:07
    Processor has been on-line since 06/11/01 21:58:26.
    The sparc processor operates at 85 MHz,
          and has a sparc floating point processor.

  After applying the most recent patch cluster from Sun,
  I now get a strange warning when compiling TK. 

  I get this warning on every .c file that gets compiled.

  Here is a sample:
  gcc -pipe -c -O -Wall -Wconversion -Wno-implicit-int
  -fPIC  -I/export/home/tmh/work/tk8.4a3/unix
  -I/export/home/tmh/work/tk8.4a3/unix/../generic 
  -I/export/home/tmh/work/tk8.4a3/unix/../bitmaps
  -I/export/home/tmh/work/tcl8.4a3/generic
  -I/usr/openwin/include  -DHAVE_UNISTD_H=1
  -DHAVE_LIMITS_H=1 -D_REENTRANT=1 -DHAVE_SYS_SELECT_H=1
  -DHAVE_SYS_TIME_H=1      -DTCL_NO_DEPRECATED 
  /export/home/tmh/work/tk8.4a3/unix/tkUnixSend.c
  In file included from
  /export/home/tmh/work/tk8.4a3/unix/../generic/tk.h:83,
                   from
  /export/home/tmh/work/tk8.4a3/unix/../generic/tkPort.h:20,
                   from
  /export/home/tmh/work/tk8.4a3/unix/tkUnixSend.c:18:
  /usr/openwin/include/X11/Xlib.h:32: warning: ignoring
  pragma: "@(#)Xlib.h       1.10    00/10/12 SMI
  In file included from
  /export/home/tmh/work/tk8.4a3/unix/../generic/../unix/tkUnixPort.h:82,
                   from
  /export/home/tmh/work/tk8.4a3/unix/../generic/tkPort.h:32,
                   from
  /export/home/tmh/work/tk8.4a3/unix/tkUnixSend.c:18:
  /usr/openwin/include/X11/Xresource.h:56: warning:
  ignoring pragma: "@(#)Xresource.h     1.2     1.2 SMI
  In file included from
  /export/home/tmh/work/tk8.4a3/unix/../generic/../unix/tkUnixPort.h:83,
                   from
  /export/home/tmh/work/tk8.4a3/unix/../generic/tkPort.h:32,
                   from
  /export/home/tmh/work/tk8.4a3/unix/tkUnixSend.c:18:
  /usr/openwin/include/X11/Xutil.h:56: warning: ignoring
  pragma: "@(#)Xutil.h     1.2     00/07/05 SMI

  This does not seem to prevent compilation, It is just
  very messy.

  I have the most recent CVS head of tk8.4a3 (from Jun
  12).

  I am using gcc 

  flare: [7] > gcc -v
  Reading specs from
  /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/specs
  gcc version 2.95.2 19991024 (release)


tkt_uuid: 433283ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 79. L10N
priority: 6
foundin: None
resolution: Fixed
title: correct Unix utf-8 copy & paste support
comment:
  The following patch adds support on unix for copy & 
  paste of UTF8_STRING, which is becoming a standard for 
  passing around unicode data.

  It works in the following way:

  When a paste into Tk operation is requested (using 
  selection get -type UTF8_STRING), Tk makes sure not to 
  loose bits in encoding.

  When a copy request from the system comes in asking 
  for a UTF8_STRING, we allow any selection handler of 
  type XA_STRING to act instead, as utf-8 is out 
  internal format.  When this happens, we make sure not 
  to downconvert the data (via encoding conversion) 
  before returning it to the system.  This allows all 
  widgets to automatically support exporting UTF8_STRING 
  data without adding a new selection handler.

  Finally, for the widgets to get UTF8_STRING data from 
  inside out outside sources that provide it, a new 
  method ::tk::GetSelection was added that prioritizes 
  asking for UTF8_STRING on unix.

  All this is only relevant on Unix.

  For more inforamation, see:

  http://www.cl.cam.ac.uk/~mgk25/unicode.html#x11

  The patch is against 8.4a3cvs.


tkt_uuid: 434205ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Invalid
title: itemconfigure doesn't work on Win2000
comment:
  When trying to use itemconfigure with a listbox on 
  windows 2000, TK reports that it isn't a valid 
  option.  i.e. "bad option "itemconfigure": must be 
  active,bbox...." etc. Tried this under TCL 8.4 as well 
  and got same result.  Same script works fine on 
  Windows 95 and 98.

  #######  this was the proc that failed
  proc writeLine {} {
      # Writes out one line of data to the list box
      incr g::lineNo
      .listb insert end $g::line
      # If more than 7 days old then put line item in 
  yellow
      if {$g::testTime > 7} {
          .listb itemconfigure $g::lineNo -background 
  yellow
      }
  }


tkt_uuid: 434537ffffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Duplicate
title: tkUnixDraw.c", line 97: error 1563: Expr
comment:
  During the make I get:
  tkUnixDraw.c", line 97: error 1563: Expression in if 
  must be scalar

  Line 97 is a submitted by problem # 220747.

  HPUX 11.00 gcc v2.8.1

  Any help would be very nice.


tkt_uuid: 435660ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: Mac code changes up-port from 8.3.3 Tk
comment:
  Attached the patch bringing forward the mac specific 
  code changes from Tk 8.3.3 and adding some new changes 
  for 8.4.  A detailed ChangeLog is included.

  New 8.4 changes include a mac resource reorganization 
  and a fix to tkMacButton.c.

  The changes from 8.3.3 have already been looked at 
  briefly by Jeff Hobbs when he checked them in for 8.3.3, 
  but I am grateful for more code review. 

  new files and modified binary files are attached 
  separately.

  The following file can be removed from the repository 
  when committing this patch: (in tk/mac/) tkMacShLib.exp

  one file affected by this patch is in an area that I 
  don't co-maintain; a trivial, mac conditionalized change 
  to tkPointer.c

  Approval for committing this patch is thus needed from 
  the maintainers of the following areas:

  63.Generic Window Operations - JH - generic/tkPointer.c


tkt_uuid: 436817ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: Wont Fix
title: Courier 12 Underline font problem
comment:
  I am using the 8.3.3 release of tcl/tk, under windows, 
  and have noticed that Courier 12 Underlined doesn't 
  display correctly in the text widget.

  Consider the following

  toplevel .foo
  text .foo.bar -font {Courier 12 underline}

  pack .foo.bar

  As you type in the window, the font being displayed 
  does not have any underlined characters.

  If you then change the font as follows:-

  .foo.bar conf -font {Courier 10 underline}

  the display shows text that has been underlined.

  Trying several different fonts, it appears that 
  Courier (or Courier New) size 12 only displays this 
  behaviour.


tkt_uuid: 437149ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Duplicate
title: clipboard,event click, focus tests fail
comment:
  3 different test suite scripts show failures in
  the recent release.

  Platform: SPARC Solaris 2.6
  Compiler: SPARC Sun 5.1
  Configure arguments: --prefix=/usr/tcl84
  Window manager: CDE


  clipboard.test

  ==== clipboard-6.2 Tk_ClipboardAppend procedure FAILED
  ==== Contents of test case:

      setupbg
      clipboard clear
      clipboard append -f INTEGER -t TEST "16"
      set result [dobg {clipboard get TEST}]
      cleanupbg
      set result

  ---- Result was:
  CLIPBOARD selection doesn't exist or form "TEST" not
  defined
  ---- Result should have been:
  0x10
  ==== clipboard-6.2 FAILED


  event.test

  ==== event-click-drag-1.2  click and drag in an entry
  widget, this
                              tests tkEntryMouseSelect in
  entry.tcl  FAILED
  ==== Contents of test case:

      destroy .t
      set t [toplevel .t]
      set e [entry $t.e]
      pack $e
      tkwait visibility $e
      focus -force $e
      _keypress_string $e "A Tcl/Tk selection test!"
      set anchor 6
      set selend 18

      set result [list [$e get]]

      # Get the x,y coords of the second T in "Tcl/Tk"
      foreach {anchor_x anchor_y} [_text_ind_to_x_y $e
  $anchor] break

      # Click down to set the insert cursor position
      event generate $e <Enter>
      event generate $e <ButtonPress-1> -x $anchor_x -y
  $anchor_y

      # Save the position of the insert cursor
      lappend result [$e index insert]
      
      # Now drag until selend is highlighted, then click
  up

      set current $anchor
      while {$current <= $selend} {
          foreach {current_x current_y} [_text_ind_to_x_y
  $e $current] break
          event generate $e <B1-Motion> -x $current_x -y
  $current_y
          incr current
          _pause 50
      }

      event generate $e <ButtonRelease-1> -x $current_x
  -y $current_y
      _pause 200

      # Save the position of the insert cursor
      lappend result [$e index insert]

      # Save the highlighted text
      lappend result [selection get]

      # Now click and click and drag to the left, over
  "Tcl/Tk selection"

      event generate $e <ButtonPress-1> -x $current_x -y
  $current_y

      while {$current >= ($anchor - 4)} {
          foreach {current_x current_y} [_text_ind_to_x_y
  $e $current] break
          event generate $e <B1-Motion> -x $current_x -y
  $current_y
          incr current -1
          _pause 50
      }

      event generate $e <ButtonRelease-1> -x $current_x
  -y $current_y
      _pause 200

      # Save the position of the insert cursor
      lappend result [$e index insert]

      # Save the highlighted text
      lappend result [selection get]


  ---- Result was:
  {A Tcl/Tk selection test!} 6 18 {Tk selection} 4 {l/Tk
  selection}
  ---- Result should have been:
  {A Tcl/Tk selection test!} 6 18 {Tk selection} 2
  {Tcl/Tk selection}
  ==== event-click-drag-1.2 FAILED

  filebox.test
  focus.test

  ==== focus-5.1 ChangeXFocus procedure, don't take focus
  unless have it FAILED
  ==== Contents of test case:

      focusSetup
      focus -force .t
      update
      set result [focus]
      send [dobg {tk appname}] {focus -force .; update}
      lappend result [focus]
      focus .t.b2
      update
      lappend result [focus]

  ---- Result was:
  .t .t {}
  ---- Result should have been:
  .t {} {}
  ==== focus-5.1 FAILED


tkt_uuid: 437282ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Invalid
title: Windows button -highlight* broken
comment:
  OK, if it's not actually broken, the behavior inconsistent, and the fix is not readily apparent from the documenation, and the fix might cause portability problems (different behavior on different platforms.


  Run the following code snippit in wish 8.3.3 on Linux.

      toplevel .t
      button .t.b -text "Foo" -command {puts stdout "Foo!"} -highlightthickness 2 -highlightcolor red -highlightbackground red -borderwidth 0
      pack .t.b

  And you should see a flat button with a 2bit red box around it.


  However, under Windows, the same code snippet results in no visible border (although the widget >is< sized correctly to accomodate the border).  However, if you then type

      .t.b configure -default active

  The missing border is displayed correctly (correct == in the manner displayed under Unix, which is what is described in the documentation, and is what I expect it to be doing).

  The culprit code appears to be in tk/win/winButton.c, around line 399.  At this point, highlightthickness is overridden and forced to zero if the "-default" option is not "active".  A brief perusal of tk/unix/unixButton.c does not turn up a similar value stomp; however, I didn't do a detailed walkthru so it may have eluded me.


  Something that just occurred to me is that the default setting for "-default" may be different between the two platforms.  I haven't checked that.

  I haven't checked Mac behavior, either.


tkt_uuid: 438247ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Fixed
title: tk_getSaveFile causes [mc] error
comment:
  The following script:

     % set tk_strictMotif 1
     1
     % tk_getSaveFile

  Leads to the following error when an existing file is selected and OK clicked:

    not enough arguments for all format specifiers
    not enough arguments for all format specifiers
        while executing
    "format %s%s  [::msgcat::mc {File "%1$s" already exists.\n\n}  $selectFilePath ]"
        (procedure "tkMotifFDialog_ActivateSEnt" line 39)
        invoked from within
    "tkMotifFDialog_ActivateSEnt $w"
        (procedure "tkMotifFDialog_OkCmd" line 4)
        invoked from within
    "tkMotifFDialog_OkCmd .__tk_filedialog"
        invoked from within
    ".__tk_filedialog.bot.ok invoke"
        ("uplevel" body line 1)
        invoked from within
    "uplevel #0 [list $w invoke]"
        (procedure "tkButtonUp" line 25)
        invoked from within
    "tkButtonUp .__tk_filedialog.bot.ok
    "
        (command bound to event)


tkt_uuid: 438732ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Out of Date
title: CRITICAL core dump upon startup
comment:
  After downloading the July 4th snapshot of 8.4a3
  and compiling it on my SPARC Solaris 2.6 system (with
  Sun's v 5.1 C compiler, 
  I find that I get a BUS error core dump.  Here's
  the stack trace:
   $ dbx $(whence wish) core
  Reading wish
  core file header read successfully
  Reading ld.so.1
  Reading libtk8.4.so
  Reading libtcl8.4.so
  Reading libsocket.so.1
  Reading libnsl.so.1
  Reading libX11.so.4
  Reading libdl.so.1
  Reading libm.so.1
  Reading libc.so.1
  Reading libmp.so.2
  Reading libXext.so.0
  Reading libdga.so.1
  Reading libc_psr.so.1
  program terminated by signal BUS (invalid address
  alignment)
  (dbx 1)
  where                                                  
  =>[1] HashArrayKey(0x385a8, 0x9800005, 0x2e130,
  0x4e0c8, 0x0, 0x0), at 0xff1d6cb0
    [2] Tcl_FindHashEntry(0xff22feb8, 0x9800005, 0x385a8,
  0x9800005, 0x1, 0x1), at 0xff1d6218
    [3] CreateWrapper(0x4e070, 0xff354e64, 0x3e2a8,
  0x3e388, 0xffbed574, 0x385ac), at 0xff2e05f4
    [4] TkWmMapWindow(0x3e388, 0xff354e64, 0x3e2a8,
  0xff3e2628, 0x0, 0x0), at 0xff2da390
    [5] Tk_MapWindow(0x3e2a8, 0xff228c0c, 0x22c90, 0x0,
  0x22ca8, 0x1), at 0xff2c8ee0
    [6] MapFrame(0x4df08, 0x4df08, 0xff228c0c, 0x22ed4,
  0x22e54, 0xffbed660), at 0xff2e9114
    [7] TclServiceIdle(0x0, 0x0, 0x2d138, 0x2fe68,
  0xfffffffd, 0x0), at 0xff1fdf24
    [8] Tcl_DoOneEvent(0x0, 0xff228c0c, 0x22c90, 0x0,
  0x22ca8, 0x1), at 0xff1ec9f0
    [9] Tk_MainLoop(0x22fe0, 0xff228c0c, 0x4, 0x0,
  0x22fe0, 0xff228c0c), at 0xff2afaac
    [10] Tk_MainEx(0xff366258, 0x2bde0, 0x0, 0x22fe0,
  0xff354e64, 0x10c04), at 0xff2bc138
    [11] main(0x1, 0xffbed9d4, 0x1, 0x20d90, 0x0, 0x0),
  at 0x10be4
  (dbx 2) 


tkt_uuid: 439320ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Wont Fix
title: distclean target doesn't always work
comment:
  Example:  Put Tk source in directory foo/tk8.3.3.  
  Configure and compile.  Move Tk directory by doing 'mv 
  foo bar'.  Try 'make distclean'.  It says:

  make: *** No rule to make target `/n/bmrca/users/lim/
  src/foo/tk8.3/unix/Makefile.in', needed by `Makefile'.  
  Stop.

  This problem does not happen with the Tcl makefile.

  My guess is that there is some kind of target problem.  
  The distclean target does not reference any fully 
  specified paths, so some other target must be getting 
  invoked unnecessarily.


tkt_uuid: 439503ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: None
title: exec command hangs
comment:
  Under Linux (RH7, MDK8) wish will hang when the exec
  command is used.  This does not happen under tclsh..

  Start wish then issue "exec ls".

  You will have to ctrl-c to kill wish.


tkt_uuid: 440664ffffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: None
title: "move" and "coords" ignore tag args
comment:
  Found in 8.4a2 under Win and Linux:

  supposed we have a canvas $c, I put a 15x15 rectangle
  into it:

  %set ID [$c create rectangle 10 10 15 15 -tags MYTAG]

  then I query the rectangle coords by using the ID:

  %$c coords $ID
  10.0 10.0 15.0 15.0

  ok, good. Let's try with MYTAG:  

  %$c coords MYTAG
  %

  nothing returns. 
  I have seen a similar behavior with "move", where the
  move is not performed if a tag is given as argument.

  This didn't happen in 8.0.x


tkt_uuid: 442835ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: None
resolution: Fixed
title: enhanced dialog.tcl - windows tk_dialog
comment:
  The tk_dialog file (dialog.tcl) has been enhanced for the windows platform to provide a frame and 
  button spacing that is cleaner and more consistent with the unix tk_dialog.  

  The frames that split the upper text area from the lower button (grid) area now display with a 
  raised relief and border width(1), as in unix,  and the pads on the text area were increased slightly 
  for better readability.

  The button area spacing has been corrected by adding a -pady value to the grid definition.


  M Harris


tkt_uuid: 443725ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 43. Photo Image|PPM
priority: 5 Medium
foundin: None
resolution: Duplicate
title: image -data does not work with PPM/PGM
comment:
  package require base64
  console show
  # work with GIF
  set targetFileName "xxx.gif"
  set tempFileName   "tmptmp.tcl"
  #With gif, it works, let's create a ppm image
  image create photo test -file xxx.gif
  test write xxx.ppm -format ppm
  # with ppm, it does not work
  set targetFileName "xxx.ppm"

  fconfigure [set fin [open $targetFileName r]] -
  translation binary
  set buf [read $fin]
  close $fin

  set encoded_buf [base64::encode $buf]

  set fout [open $tempFileName w]
  puts $fout \
   "set data {$encoded_buf}\n\
   image create photo Image1 -data \$data\n\
   button .cmda -image Image1 -command exit\n\
   pack .cmda\n\
   "
  close $fout
  puts "wrote. [file size $tempFileName] bytes. 
  reading..."
  source $tempFileName
  # end.


tkt_uuid: 443848ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: Fixed
title: 'elide' doesn't elide first newline
comment:
  The following script shows the bug:

  % text .t
  .t
  % pack .t
  % .t insert 1.0 "1111\n2222\n3333\n"
  % .t tag configure elidden -elide 1 -background red
  % .t tag add elidden 1.2 3.2

  The text widget now should contain one line with

  '1133'

  in it, but instead it contains two lines like this:

  11
  33

  and the region to the right of the '11' is actually 
  coloured red!  The bug seems to be that the newline in 
  the first line of an elided section is always 
  displayed.  (Note that the newline at the end of the 
  2222 line is correctly elided).


tkt_uuid: 444026ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: None
title: Certain canvas lines disappear (WinME)
comment:
  Certain canvas lines cannot be shown on windows ME.

  The small attached program demonstrates that a 
  combination of 3 things cause canvas lines to be 
  invisible:

   - a high number of coordinates
   - using width >= 1.5
   - using smooth

  Changing any of these will cause the line to show.

  The same program works fine under Windows 2000.


tkt_uuid: 444169ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: None
title: Keyboard traversal does not work
comment:
  If you make a menubar out of a Menu widget using
  the ". config -menu .mb" command, then try to do
  a keyboard traversal of the menu, you get an error
  message:  "grab failed: window not viewable".

  The following script reproduces the problem:

  # Create a menubar
  #
  menu .mb -type menubar
  . config -menu .mb
  .mb add cascade -label File -underline 0 -menu .mb.file
  menu .mb.file -tearoff 0
  .mb.file add command -label Exit -command exit

  # Create a frame to simulate the rest of the
  application.
  #
  frame .f -width 500 -height 300
  pack .f -side top -fill both -expand 1

  # Wait a while to let everything settle out...
  #
  update

  # Simulate a keyboard traversal of the menubar
  #
  event generate . <Alt-f>


tkt_uuid: 444458ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Fixed
title: Can't build Tk 8.4a3 (from 2001-07-23)
comment:
  Two Tk modules define static routines that conflict with 'Windows API routines:

  generic/tkCanvBmap.c

      --  static routine CreateBitmap()

  generic/tkCursor.c

      --  static routine GetCursor()

  In each case, I stuck an X in front of the name to get past the problem for now but there's 
  something wrong here.


tkt_uuid: 444900ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Works For Me
title: menu index command changed
comment:
  Under some circumstances, I'm running into:

     Tcl_AppendStringsToObj called with shared object

  when trying to invoke mnemonics (Alt-<letter>) in a UNIX GUI.  I've tracked this down to 
  tkMenuFind which includes the code:

      set last [$child index last]
      for {set i [$child cget -tearoff]} {$i <= $last} {incr i} {

  It appears that in Tk 8.2, [$m index last] returns 0 for an empty menu.  In Tk 8.4, it returns 
  "none".  Whatever the value of -tearoff (0 or 1), it's less than "none" so the loop is executed at 
  least once.  Then in the loop body

   set char2 [string index [$child entrycget $i -label] \
  [$child entrycget $i -underline]]

  Causes the Tcl_AppendStringToObj error noted above.


tkt_uuid: 445468ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: Fixed
title: specfile broken ?
comment:
  building with rpm from tar.gz file not working, 
  specfile seems to be broken. 
  the archive does even not become decompressed.


tkt_uuid: 445469ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 81. Portability
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: tk without tcl
comment:
  * separate the tcl and tk stuff so we have:

  * tk - an widget set library
  * tcl - tcl script interpreter
  * wish - tcl/tk runtime system based
  on tcl and tk

  *  tk should build completely without tcl


tkt_uuid: 446129ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Out of Date
title: patch for FreeBSD 2.2.x
comment:
  This patch corresponds to the patch submitted for Tcl bug #443170.

  --- aclocal.m4.old      Mon Jul 30 13:49:33 2001
  +++ aclocal.m4  Mon Jul 30 13:50:59 2001
  @@ -775,18 +775,20 @@
                  DL_OBJS="tclLoadDl.o"
                  DL_LIBS=""
                  LDFLAGS=""
  -               LD_SEARCH_FLAGS=""
                  AC_MSG_CHECKING(for ELF)
                  AC_EGREP_CPP(yes, [
   #ifdef __ELF__
          yes
   #endif
  -               ],
  +               ], [
                      AC_MSG_RESULT(yes)
  -                   SHARED_LIB_SUFFIX='${TCL_TRIM_DOTS}\$\{DBGX\}.so',
  +                    LD_SEARCH_FLAGS='-Wl,-rpath,${LIB_RUNTIME_DIR}'
  +                   SHARED_LIB_SUFFIX='${TCL_TRIM_DOTS}\$\{DBGX\}.so'
  +                ], [
                      AC_MSG_RESULT(no)
  +                    LD_SEARCH_FLAGS='-Wl,-L${LIB_RUNTIME_DIR}'
                      SHARED_LIB_SUFFIX='${TCL_TRIM_DOTS}\$\{DBGX\}.so.1.0'
  -               )
  +               ])
              ], [
                  SHLIB_CFLAGS=""
                  SHLIB_LD="echo tclLdAout $CC \{$SHLIB_CFLAGS\} | `pwd`/tclsh -r"


tkt_uuid: 446624ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Out of Date
title: patch for FreeBSD 2
comment:
  This patch corresponds to the patch submitted for Tcl
  bug #446622.

  --- aclocal.m4.old      Tue Jul 31 16:56:23 2001
  +++ aclocal.m4  Tue Jul 31 16:57:05 2001
  @@ -1102,6 +1102,14 @@
                  fi
              fi
          fi
  +
  +       AC_MSG_CHECKING(for brk declaration in
  unistd.h)
  +       AC_EGREP_HEADER(brk, unistd.h, [
  +           AC_DEFINE(BRK_DECLARED)
  +           AC_MSG_RESULT(yes)
  +       ], [
  +           AC_MSG_RESULT(no)
  +       ])
       fi
   
       # Step 5: disable dynamic loading if requested via
  a command-line switch.


tkt_uuid: 446699ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Works For Me
title: label configure -state active crashes
comment:
  Running tcl/tk 8.3.3 on Windows 2000; fatal crash when feeding the following script to wish83:
      label .l -text Foo -highlightthickness 2 -background white -highlightcolor red -highlightbackground green
      pack .l
      .l configure -state active


tkt_uuid: 448802ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Fixed
title: Missing files in source distro
comment:
  The Tk 8.4a3 source code distribution is missing 
  some of its files:

  library/msgs/*.msg
  unix/tcl.m4
  win/tcl.m4

  The 'make dist' target needs to be updated to be
  sure these files are included.


tkt_uuid: 449161ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Wont Fix
title: using gcc on Solaris produces warnings
comment:
  On SunOS 5.7 (Solaris 7), using configure --enable-gcc
  to use gcc (I'm using gcc 2.95.2) produces tons of
  warning as follows:

  In file included from
  /n/bmrca/users/lim/src/original/tk8.3.3/unix/../generic/tk.h:83,
                   from
  /n/bmrca/users/lim/src/original/tk8.3.3/unix/../generic/tkInt.h:21,
                   from
  /n/bmrca/users/lim/src/original/tk8.3.3/unix/../generic/tk3d.h:18,
                   from
  /n/bmrca/users/lim/src/original/tk8.3.3/unix/../generic/tk3d.c:16:
  /usr/openwin/include/X11/Xlib.h:32: warning: ignoring
  pragma: "@(#)Xlib.h       1.7     00/09/27 SMI

  It would be nice if compiling Tk didn't spew out tons
  of these warnings.  Here is a patch to eliminate them
  (only on Solaris):

  --- aclocal.m4.old      Wed Aug  8 07:39:09 2001
  +++ aclocal.m4  Wed Aug  8 07:51:59 2001
  @@ -985,6 +985,9 @@
              DL_LIBS="-ldl"
              if test "$using_gcc" = "yes" ; then
                 
  LD_SEARCH_FLAGS='-Wl,-R,${LIB_RUNTIME_DIR}'
  +
  +                # Solaris headers contain pragmas
  +               CFLAGS_WARNING="${CFLAGS_WARNING}
  -Wno-unknown-pragmas"
              else
                  LD_SEARCH_FLAGS='-R ${LIB_RUNTIME_DIR}'
              fi


tkt_uuid: 449428ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Works For Me
title: Does not work with invalid directory
comment:
  With the currrent implementation it is impossible to
  enter
  a name of an invalid directory, even if "-mustexist
  false" is specified. Looks like the sourcecode has to
  be changed as the attached patch shows.


tkt_uuid: 450020ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: None
resolution: Invalid
title: Messages for czech language
comment:
  Hi,

  I post file of messages for Tk in czech language.
  I wil be happy to include this i distribution.

  Commenst are welcome.

  Michal


tkt_uuid: 450504ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: unicode and 'insert -1l' causes garbage
comment:
  text .t
  pack .t
  # dispay a bullet-space-abc and space-space-def
  .t insert 1.0 "\u2022 abc\n  def\n"
  .t mark set insert 2.2
  .t mark set insert "insert -1l"
  # oops the bullet has been turned into three chars
  # of garbage!

  Generally speaking the text widget's calculation of +/-
   1 line is wrong, since it counts in bytes and not in 
  characters.  This means repeated 'mark set 
  insert "insert -1l"' does not maintain a constant 
  horizontal position.  However the above script shows 
  us this can really result in garbage when the widget 
  tries to place the insertion point in the middle of a 
  multi-byte unicode character!

  The first part of the bug seems to be acknowledged 
  here in tkTextIndex.c (line 724):

  /*
   * This doesn't work quite right if using a 
  proportional font or
   * UTF-8 characters with varying numbers of bytes.  
  The cursor will
   * bop around, keeping a constant number of bytes (not 
  characters)
   * from the left edge (but making sure not to split 
  any UTF-8
   * characters), regardless of the x-position the index 
  corresponds
   * to.  The proper way to do this is to get the x-
  position of the
   * index and then pick the character at the same x-
  position in the
   * new line.
   */

  TkTextMakeByteIndex(indexPtr->tree, lineIndex, 
  indexPtr->byteIndex,
  indexPtr);

  But, apparently the "making sure not to split any UTF-
  8 characters" bit is incorrect.

  (Note: Tcl/Tk 8.4a4 on Windows 2000, but the problem 
  is in the generic code).


tkt_uuid: 451777ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Objectify grid and pack.
comment:
  This patch objectifies the grid and pack commands.

  Parts of the patch for bug #418664 are included since there were
  similar changes in this patch and the other version was better.


tkt_uuid: 452040ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: None
resolution: Fixed
title: grid mishandles adjacent 'x' and '^'
comment:
  the grid command handles ^ wrong when preceeded by an x

  Example that demos problem:

  foreach l {a b c d e f} {
     label .$l -text $l -relief raised -bd 2
  }

  # example 1
  # should stretch 'b', 
  #   but actually stretches 'a'
  # NOTE: that .e is still in correct position
  grid .a .b .c .d -sticky news
  grid  x  ^  x .e -sticky news

  # cleanup
  grid forget .a .b .c .d .e

  # example 2
  # should stretch 'a' & 'c', 
  #   but actually stretches 'a' & 'b'
  # NOTE: that .e is still in correct position
  grid .a .b .c .d -sticky news
  grid  ^  x  ^ .e -sticky news

  # cleanup
  grid forget .a .b .c .d .e

  # example 3 (this is correct if actual widgets used)
  grid .a .b .c .d -sticky news
  grid  ^ .e  ^ .f -sticky news


  I glanced at the code, but saw nothing obvious (it
  was too complicated for me to follow at first look)
  but I did notice a fix for bug #1386 which corrected
  the handling of consecutive '^' so it might be in same
  area as that fix. I'll keep looking & see if I can 
  offer a fix, but you probably can find it quicker if
  you are familiar with the code.

  Bruce Hartweg


tkt_uuid: 452713ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Works For Me
title: repeated test runs give diff. results
comment:
  Environment:
  Sun Ultra 5 running Solaris 7
  Sun WorkShop Compiler 5.0
  logged in at console

  I did the following:

  cd tcl8.3.3/unix
  make -s distclean
  configure
  make -s
  make -s test
  cd tk8.3.3/unix
  make -s distclean
  configure
  make -s
  make -s test > test.1
  make -s test > test2
  make -s test > test3

  All 3 test runs gave different results, with different
  tests succeeding and failing.  I did nothing in between
  the test runs and no one else was using the machine. 
  Contrary to comments made in comp.lang.tcl, socket
  usage and slow X connections had nothing to do with the
  failed tests.  I'm attaching the output of the 3 test
  runs.


tkt_uuid: 453518ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: None
title: Windows 16-bit color masks are wrong
comment:
  tkWinX.c specifies a value of FC for the green_mask in
  16 bit mode.  While 5-6-5 is a supported Windows DIB
  format, a quick glance at tkWinImage.c (line 140) shows
  that Tk uses the 5-5-5 format.  Therefore, the value
  should be F8 for R, G, and B.

  Here is a patch to correct it:

  --- tkWinX.c.old        Mon Jul  9 12:46:10 2001
  +++ tkWinX.c    Mon Aug 20 14:35:22 2001
  @@ -383,7 +383,7 @@
              screen->root_visual->class = TrueColor;
              screen->root_visual->map_entries = 64;
              screen->root_visual->red_mask = 0xf8;
  -           screen->root_visual->green_mask = 0xfc00;
  +           screen->root_visual->green_mask = 0xf800;
              screen->root_visual->blue_mask = 0xf80000;
          } else if (screen->root_depth >= 24) {
              screen->root_visual->class = TrueColor;


tkt_uuid: 453624ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: None
title: setgrid+highlightthick 0 broken
comment:
  If you have a text widget that is -setgrid true and
  -highlightthickness 0, it will resize incorrectly
  ending up resizing slightly more or slightly less than
  the actual size of a line (vertically) and thus making
  -setgrid true useless when -highthick is 0.

  When -highthick is not 0 (left to the default, in
  specific) the gridding works fine.


tkt_uuid: 454303ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 09. [listbox]
priority: 3 Low
foundin: None
resolution: None
title: &quot;-justify&quot; option in listboxes
comment:
  I was looking for a justify option in the TK8.3/8.4 
  listbox command and I found this old patch by Robin 
  Becker.
  This allows tk8.0 to show a "-justify" options to 
  align the listbox content to left/center/right.
  Unfortunately I haven't the necessary knowledge 
  neither to judge if it is still a good patch for the 
  new tcl releases, nor to put my hands on the TclTk 
  source code.

  This is the patch as I found it on 

  http://www.jessikat.demon.co.uk/tkLB8.patch

  Stefano Federici
  s_federici@yahoo.com

  =================LISTBOX PATCH====================

  *** tkListbox.c.orgSat Jan 18 23:54:36 1997
  --- tkListbox.cSun Jan 19 00:04:46 1997
  ***************
  *** 167,172 ****
  --- 167,173 ----
        char *xScrollCmd;/* Command prefix for 
  communicating with
     * horizontal 
  scrollbar.  NULL means no command
     * to issue.  
  Malloc'ed. */
  +     int justify;/* justification 
  option */
        int flags;/* Various 
  flag bits:  see below for
     * definitions. */
    } Listbox;
  ***************
  *** 259,264 ****
  --- 260,267 ----
        {TK_CONFIG_STRING, "-
  yscrollcommand", "yScrollCommand", "ScrollCommand",
    DEF_LISTBOX_SCROLL_COMMAND, Tk_Offset(Listbox, 
  yScrollCmd),
    TK_CONFIG_NULL_OK},
  +     {TK_CONFIG_JUSTIFY, "-
  justify", "justify", "Justify",
  + "left", Tk_Offset(Listbox, justify), 
  TK_CONFIG_NULL_OK},
        {TK_CONFIG_END, (char *) NULL, (char *) NULL, 
  (char *) NULL,
    (char *) NULL, 0, 0}
    };
  ***************
  *** 415,420 ****
  --- 418,424 ----
        listPtr->takeFocus = NULL;
        listPtr->xScrollCmd = NULL;
        listPtr->yScrollCmd = NULL;
  +     listPtr->justify = TK_JUSTIFY_LEFT;
        listPtr->flags = 0;
    
        Tk_SetClass(listPtr->tkwin, "Listbox");
  ***************
  *** 1188,1195 ****
    }
    Tk_GetFontMetrics(listPtr->tkfont, &fm);
    y += fm.ascent + listPtr->selBorderWidth;
  ! x = listPtr->inset + listPtr->selBorderWidth - 
  elPtr->lBearing
  ! - listPtr->xOffset;
    Tk_DrawChars(listPtr->display, pixmap, gc, 
  listPtr->tkfont,
    elPtr->text, elPtr->textLength, x, y);
    
  --- 1192,1206 ----
    }
    Tk_GetFontMetrics(listPtr->tkfont, &fm);
    y += fm.ascent + listPtr->selBorderWidth;
  ! if (listPtr->justify == TK_JUSTIFY_LEFT) {
  ! x = listPtr->inset + listPtr-
  >selBorderWidth - elPtr->lBearing
  ! - listPtr->xOffset;
  ! } else if (listPtr->justify == 
  TK_JUSTIFY_CENTER) {
  ! x = listPtr->selBorderWidth - elPtr-
  >lBearing
  ! - listPtr->xOffset + (Tk_Width
  (tkwin) - elPtr->pixelWidth) / 2;
  ! } else {
  ! x = Tk_Width(tkwin) - 2*listPtr-
  >inset - elPtr->pixelWidth;
  ! }
    Tk_DrawChars(listPtr->display, pixmap, gc, 
  listPtr->tkfont,
    elPtr->text, elPtr->textLength, x, y);
    


tkt_uuid: 454861ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Invalid
title: incorrect X masks used on Windows
comment:
  This is a little complicated.  Let me know if I need to
  clarify anything.

  On Windows, Tk draws images onto the screen with
  TkPutImage, which is an emulation of XPutImage. 
  TkPutImage blits it as a DIB so the XImage data format
  on Windows is DIB format.  In 32-bit mode, the first
  four bytes (the first pixel) of a DIB looks like this:

  BB GG RR 00

  Now if you look at this from the point of view of an
  XImage, this is an XImage in ZPixmap format in LSBFirst
  byte order (as specified by Tk).  With X, you can read
  the 32-bit pixel directly as a 32-bit integer.  Since
  you're on a little-endian processor, you'd get:

  0x00RRGGBB

  Therefore, the values of the Z bit masks are supposed
  to be:

  red_mask = 0xFF0000
  green_mask = 0xFF00
  blue_mask = 0xFF

  Tk 8.3.3 has these values:

  red_mask = 0xff
  green_mask = 0xff00
  blue_mask = 0xff0000

  So why does the color work ok?  As far as I can tell,
  the only code that accesses the pixels directly is the
  image code.  The ImageGetPixel and PutPixel routines
  inadvertantly swap things around so it actually matches
  the incorrect masks.  The code looks correct, but it's
  not.  The Windows GetRValue, GetGValue, and GetBValue
  macros are intended for COLORREF format, which is
  0x00BBGGRR.

  The same problem occurs with 24-bit images too.  The
  only difference is there's no zero padding for 24 bit.

  We discovered this bug because our software manipulates
  XImages directly, in a platform independent manner.

  Luckily, this bug seems pretty isolated from the rest
  of Tk.  The patches below are fairly simple.  I ran the
  fixed code through the Tk test suite and did not see
  any new errors.  I tested the fixed code with images
  and with colored buttons at 8, 16, 24, and 32 bit
  depths.

  Note that the new code is slightly faster in 32-bit
  mode because it copies pixels as 32-bit ints (like
  you're supposed to be able to do) instead of swapping
  bytes around.


  --- tkWinX.c.old        Mon Aug 20 14:35:22 2001
  +++ tkWinX.c    Thu Aug 23 21:38:37 2001
  @@ -388,9 +388,9 @@
          } else if (screen->root_depth >= 24) {
              screen->root_visual->class = TrueColor;
              screen->root_visual->map_entries = 256;
  -           screen->root_visual->red_mask = 0xff;
  +           screen->root_visual->red_mask = 0xff0000;
              screen->root_visual->green_mask = 0xff00;
  -           screen->root_visual->blue_mask = 0xff0000;
  +           screen->root_visual->blue_mask = 0xff;
          }
       }
       screen->root_visual->bits_per_rgb =
  screen->root_depth;


  --- tkWinImage.c.old    Mon Jul  9 12:46:10 2001
  +++ tkWinImage.c        Thu Aug 23 21:38:37 2001
  @@ -75,8 +75,11 @@
   
       switch (image->bits_per_pixel) {
          case 32:
  +           pixel = (*(DWORD*)srcPtr);
  +           break;
          case 24:
  -           pixel = RGB(srcPtr[2], srcPtr[1],
  srcPtr[0]);
  +           pixel = (srcPtr[0] | ((WORD) srcPtr[1] <<
  8)
  +                   | ((DWORD) srcPtr[2] << 16));
              break;
          case 16:
              pixel = RGB(((((WORD*)srcPtr)[0]) >> 7) &
  0xf8,
  @@ -124,18 +127,19 @@
       switch  (image->bits_per_pixel) {
          case 32:
              /*
  -            * Pixel is DWORD: 0x00BBGGRR
  +            * Pixel is DWORD: 0x00RRGGBB
               */
   
  -           destPtr[3] = 0;
  +           (*(DWORD*)destPtr) = pixel;
  +           break;
          case 24:
              /*
  -            * Pixel is triplet: 0xBBGGRR.
  +            * Pixel is triplet: 0xRRGGBB.
               */
   
  -           destPtr[0] = (unsigned char)
  GetBValue(pixel);
  -           destPtr[1] = (unsigned char)
  GetGValue(pixel);
  -           destPtr[2] = (unsigned char)
  GetRValue(pixel);
  +           destPtr[0] = (unsigned char) pixel;
  +           destPtr[1] = (unsigned char) (((WORD)
  (pixel)) >> 8);
  +           destPtr[2] = (unsigned char) ((pixel) >>
  16);
              break;
          case 16:
              /*
  @@ -245,9 +249,9 @@
                  + (bitmap_pad - 1)) >> 3) &
  ~((bitmap_pad >> 3) - 1);
       }
   
  -    imagePtr->red_mask = 0;
  -    imagePtr->green_mask = 0;
  -    imagePtr->blue_mask = 0;
  +    imagePtr->red_mask = visual->red_mask;
  +    imagePtr->green_mask = visual->green_mask;
  +    imagePtr->blue_mask = visual->blue_mask;
   
       imagePtr->f.put_pixel = PutPixel;
       imagePtr->f.get_pixel = ImageGetPixel;


tkt_uuid: 455468ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: selecting text (shift up arrow)
comment:
  There is small mistake in file "tk/library.text.tcl" at
  line 111.

  tkT::extKeySelect %W [tk::TextUpDownLine %W -1]
   ^^^^^^

  may be

  tk::TextKeySelect %W [tk::TextUpDownLine %W -1]

  Michal


tkt_uuid: 456299ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 7 High
foundin: obsolete: 8.4a2
resolution: Duplicate
title: Distorted images in Win2000 menus
comment:
  This bug occurs on Win2000 only.  WinNT, WinME, Win98,
  and Win95 (and of course Unix) all appear to work
  correctly.

  When a menu entry is an image instead of text, the
  first time the image is drawn it is distorted.  It
  appears as if the clip mask is offset up and to the
  left by 3 pixels.  The distortion appears only when
  the menu first pops up.  If you drag the mouse over
  the menu entry with the image, the image is repainted
  and is drawn correctly.

  The following script is sufficient to reproduce the
  problem:

    image create photo img4 -data {
     R0lGODlhEQAeAPEDAAEBAQAz/////wAAACH5
     BAUAAAMALAAAAAARAB4AAAJjnAepeqcCo2Am  
     yQsTArivD4ZiiDRlA5Sp6pzr2aLm+tJmFcN3
     yus3+/o5NMJd8XgLIE1KQ6CZfD4Hyun0UKVq
     qdWmd4vNbrtMJ9R6baC5SOlSWNtUiDhcr24H
     4lu2+8xFQ1QAADv/
    }
    menubutton .b -text {Press Me} -menu .b.m1
    pack .b
    menu .b.m1 -tearoff 0 -background white \ 
        -activebackground white
    .b.m1 add command -image img4 -command exit


tkt_uuid: 456548ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: None
priority: 5 Medium
foundin: None
resolution: Remind
title: Tk work with non-wish event loops
comment:
  With a Tcl_SetMainLoop call in Tk 8.4 and migrating
  back to 8.3.4, it's time to start testing Tk as
  a loadable package.  After setting up an
  appropriate pkgIndex.tcl file for Tk...
  Here's one problem:

  $ cat test.tcl
  package require Tk
  after 10000 {set forever 1}
  after 1000 {destroy .}
  after 2000 {bell}
  vwait forever
  $ tclsh test.tcl
  bgerror failed to handle background error.
      Original error: can't invoke "bell" command: 
  application has been destroyed
      Error in bgerror: can't invoke "option" command: 
  application has been destroyed

  Note that all Tk commands get disabled when the
  "." window is destroyed on the theory that the
  "application has been destroyed".  Inside a wish
  event loop, it's true that destroying all windows
  exits the application, but a loadable Tk will find
  itself running inside other event loops.  It needs
  to handle that situation better.


tkt_uuid: 456632ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 6
foundin: obsolete: 8.4a4
resolution: Fixed
title: Tk_OptionTable handling flawed
comment:
  This is a verbatim copy of an email I sent to others:

  In the move from Tk 8.0 to 8.1 (or thereabouts), a new 
  and clever
  way of storing the optionTable data for the widget (to 
  work with
  the objectification of optionTables) was created.  I'm 
  now finding
  a serious flaw in those changes (Scott was noted in 
  the CVS fixes,
  but I don't know where the idea originated) - you 
  can't do this
  and for commands that are namespace imported.

  To jog memories, the change was something to the 
  effect of using
  the clientData field of the created command object to 
  store the
  initialized optionTable info in (before this was used 
  to cache
  the Tk_MainWindow result).  This looks like (from 
  tkButton.c,
  r1.1 -> r1.3):

  ***************
  *** 311,333 ****
     */
    
    static int
  ! ButtonCreate(clientData, interp, argc, argv, type)
  !     ClientData clientData;    /* Main window 
  associated with
  !                                * interpreter. */
        Tcl_Interp *interp;               /* Current 
  interpreter. */
  !     int argc;                 /* Number of 
  arguments. */
  !     char **argv;              /* Argument strings. */
        int type;                 /* Type of button to 
  create: TYPE_LABEL,
                                   * TYPE_BUTTON, 
  TYPE_CHECK_BUTTON, or
                                   * TYPE_RADIO_BUTTON. 
  */
    {
  !     register TkButton *butPtr;
  !     Tk_Window tkwin = (Tk_Window) clientData;
  !     Tk_Window new;
  ! 
  !     if (argc < 2) {
  !       Tcl_AppendResult(interp, "wrong # args: should 
  be \"",
  !               argv[0], " pathName ?options?\"", 
  (char *) NULL);
          return TCL_ERROR;
        }
    
  --- 556,597 ----
     */
    
    static int
  ! ButtonCreate(clientData, interp, objc, objv, type)
  !     ClientData clientData;    /* Option table for 
  this widget class, or
  !                                * NULL if not created 
  yet. */
        Tcl_Interp *interp;               /* Current 
  interpreter. */
  !     int objc;                 /* Number of 
  arguments. */
  !     Tcl_Obj *CONST objv[];    /* Argument values. */
        int type;                 /* Type of button to 
  create: TYPE_LABEL,
                                   * TYPE_BUTTON, 
  TYPE_CHECK_BUTTON, or
                                   * TYPE_RADIO_BUTTON. 
  */
    {
  !     TkButton *butPtr;
  !     Tk_OptionTable optionTable;
  !     Tk_Window tkwin;
  ! 
  !     optionTable = (Tk_OptionTable) clientData;
  !     if (optionTable == NULL) {
  !       Tcl_CmdInfo info;
  !       char *name;
  ! 
  !       /*
  !        * We haven't created the option table for 
  this widget class
  !        * yet.  Do it now and save the table as the 
  clientData for
  !        * the command, so we'll have access to it in 
  future
  !        * invocations of the command.
  !        */
  ! 
  !       TkpButtonSetDefaults(optionSpecs[type]);
  !       optionTable = Tk_CreateOptionTable(interp, 
  optionSpecs[type]);
  !       name = Tcl_GetString(objv[0]);
  !       Tcl_GetCommandInfo(interp, name, &info);
  !       info.objClientData = (ClientData) optionTable;
  !       Tcl_SetCommandInfo(interp, name, &info);
  !     }
  ! 
  !     if (objc < 2) {
  !       Tcl_WrongNumArgs(interp, 1, objv, "pathName ?
  options?");
          return TCL_ERROR;
        }

  So what's the problem?  If you were to create the 
  command in a
  namespace, say ::vu::dial, export dial and then import 
  dial into
  :: (or any other namespace), the command that gets 
  called is
  actually a special obj command whose objClientData 
  field is
  already used for the ImportCommand - you can't reset 
  it.  This
  manifests itself in the core simply:

  lorax [~/build/8333/tk8.3] 27 > wish8.3
  % namespace export -clear *
  % namespace eval ::foo { namespace import ::button }
  % namespace eval ::foo { ::foo::button .b }
  .b
  % namespace eval ::foo { ::foo::button .c }
  Segmentation fault

  The first call changes objClientData, causing the 
  second call
  to seg fault.  While this is an odd case for the core, 
  this would
  be common for extension authors who create their 
  widgets in
  namespaces that people import as a matter of course.  
  This only
  affects them when they use this model for the new obj-
  ified
  optionTable setup.

  My thinking was to rework this to use 
  ThreadSpecificData fields.
  Does anyone see a problem with that?  Is there perhaps 
  a better
  way that I'm missing?


tkt_uuid: 456732ffffffffffffffffffffffffffffffffff
type: Support
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
title: make TK_NO_SECURITY runtime switchable
comment:
  I've been asked several times and wondered myself 
  about making the TK_NO_SECURITY switch something that 
  happens at runtime, not compile time.  Attached is a 
  patch which effects this by adding a 'tk securesend' 
  command that operates on a per-display basis.  This 
  has to be called in the receiving app (the sending one 
  doesn't actually care).

  This one is set up to switch back and forth, although 
  the docs should note that once off, turning it on can 
  only give you a false sense of security.


tkt_uuid: 456761ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Accepted
title: static build support for Tk makefile.vc
comment:
  This patch adds support for static builds to
  makefile.vc.  (The current cygwin Makefile supports
  static builds, but the current makefile.vc does not.)

  The changes were patterned after ideas from the cygwin
  Makefile, the FreeWrap makefile.vc, and the incrTcl
  makefile.vc.

  Compilation tests were performed for both dynamic and
  static builds on Windows 95, NT, 98, 2000, and Me.  The
  test suite was run for both dynamic and static builds
  on Windows NT and 2000.  No problems were observed.

  This patch also updates mkd.bat and rmd.bat as follows:
   * replaced unreliable directory test with standard
  method
   * simplified mkd code
   * replaced rmd code (which prompted user) with simpler
  method


tkt_uuid: 456877ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 58. [send]
priority: 1 Zero
foundin: None
resolution: None
title: App name/send/multiple display problem
comment:
  To exercise this bug/problem, you need two X displays.
  Start a wish shell on each and make sure (by using [tk
  appname]) that they have the same name (which is no
  problem because they are on different displays, of
  course.)  Now get one wish (A) to open a new toplevel
  on the display of the other wish (B).  At this point, A
  can [send] to B (and get a reply) by using the right
  -displayof option, but B cannot [send] to A...

  I suspect that any fix for this will involve adding a
  -displayof option to [tk appname], and I'm not sure
  what additional problems exist when using [send] with
  multiple displays, at least in part because this fault
  makes testing harder.  :^(


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

  I believe this problem is in the 8.4 versions also.


tkt_uuid: 458002ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 74. Application Embedding
priority: 1 Zero
foundin: obsolete: 8.4a3
resolution: Works For Me
title: Tk library & external dependences
comment:
  Imagine the following usage scenario:

  In an application you want to embed Tcl/Tk. Due to various installation
  reasons, you don't want to provide new binaries with each tcl/tk update,
  but give the user the freedom to use any tcl/tk version he wishes, without
  the need to also update the app.

  The only solution to this, is to load and initialise tcl/tk dynamically,
  at run time, without linking with either the tcl or tk library during the
  compilation of the app.
  The app can use LoadLibrary or dlopen (or what ever else) in order to
  load the tcl library into the app and initialise tcl. This is feasible
  without any problem.
  Doing the same with the tk library is not possible, as the tk library,
  at least under unix, has dependences over the tcl lib, mainly regarding
  the symbol tclStubPtr. Runing ldd on my solaris system with 8.4a3 gives:

  ldd -d libtk8.4.so
          libsocket.so.1 =>        /usr/lib/libsocket.so.1
          libnsl.so.1 =>   /usr/lib/libnsl.so.1
          libX11.so.4 =>   /usr/lib/libX11.so.4
          libdl.so.1 =>    /usr/lib/libdl.so.1
          libm.so.1 =>     /usr/lib/libm.so.1
          libc.so.1 =>     /usr/lib/libc.so.1
          libmp.so.2 =>    /usr/lib/libmp.so.2
          libXext.so.0 =>  /usr/lib/libXext.so.0
          libdga.so.1 =>   /usr/openwin/lib/libdga.so.1
          symbol not found: Tcl_Free              (./libtk8.4.so)
          symbol not found: tclStubsPtr           (./libtk8.4.so)
          /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1

  Although tk uses stubs and initialises them in Tk_Init,
  it seems that tk library requires an external tclStubsPtr, from the
  tcl library.
  What's odd is that tclStubsPtr is really in
  tclstub8.4.a which libtk was linked with and should NOT be referred to over in
  libtcl.  Stubs was supposed to make all that blind and not have any load-time
  dependencies.

  This bug is originated by a post in comp.lang.tcl,
  (http://groups.google.com/groups?hl=en&safe=off&threadm=3B8DE6E3.3B588DA%40iit.demokritos.
  gr&rnum=1&prev=/groups%3Fq%3D%2B%2B%2B%2B%2B%2B%2B%2B%2BDynamic%2BLoad%2B
  of%2BTk%2Bfails%252C%2BUndefined%2BSymbol%2BtclStubsPtr%26meta%3Dsite%253Dgroups)

  or search groups.google.com for "Dynamic Load of Tk fails, Undefined Symbol tclStubsPtr"

  A workarround reported in this group is:
  " realized that when imbedding Tcl and Tk into another application, and 
  dynamically loading their libraries (to avoid a version dependency), on 
  Linux I needed to use the RTLD_GLOBAL flag on the dlopen so the Tcl 
  symbols would ba accessable to the Tk library." - David Liebtag

  Under windows the bug does not seem to exist, although the actual
  code that loaded the library was not posted. Perhaps it included such a 
  workarround?


tkt_uuid: 458007ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: tkstub.lib not copied to destination dir
comment:
  There is an ommission when building tk8.4a3 under
  windows, as the tk stub is not copied to the installation dir
  during "make install".
  The patch is trivial. Just add:
          copy $(TKSTUBLIB) "$(LIB_INSTALL_DIR)"
  under line 360 in win/makefile.vc :-)


tkt_uuid: 458124ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Duplicate
title: Dialog box doesn't return after button
comment:
  In Tk 8.4a3, a tk_dialog box never pops down when
  a button is pressed. This is because the buttons
  are initialized so that they set a different
  variable than the dialog code is waiting for --
  this must be a result of the Tk internal stuff
  being moved into its own namespace earlier on.

  On line 107 of lib/tk8.4/dialog.tcl there is a
  reference to »Priv(button)« which should be amended
  to »::tk::Priv(button)«. If this is done everything
  works fine.


tkt_uuid: 458162ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 34. [tk_chooseColor]
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: request for additional versions
comment:
  tk_chooseColor on non window systems is aesthetically
  "alright," but I would love to see additional versions
  (improvements) such as the different pickers available
  under the gimp (gyroscopic wheel, triangle, etc.) 


tkt_uuid: 458309ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 4
foundin: None
resolution: None
title: Wish aborts: unfreed fonts exist
comment:
  A few days ago I reported in comp.lang.tcl that in my app wish aborts during exiting.
  I have managed at last to find out what is happening.
  The bug can be reproduced at least under unix&windows, with tk8.4a3:

  #!/bin/sh
  # The next line is executed by /bin/sh, but not tcl \
  exec wish "$0" ${1+"$@"}

  ## Create a named font:
  font create MyFont -family arial -size 16 -weight bold

  ## Create a canvas...
  canvas .x -bg white -width 440 -height 240
  ## Place some items...
  .x create rectangle 30 30 400 200 -tags rect -fill yellow
  .x create text 220 90 -tags text -text {Click on me to abort :-)} -font MyFont \
     -anchor c

  ## Place some bindings. Just a simple pop-up...
  .x bind rect <1> {my_popup .x}
  .x bind text <1> {my_popup .x}

  pack .x -fill both -expand 1 -padx 2 -pady 2

  ## Here is all nice work done:-)
  ## I create the popup, but I wait until it is destroyed. But this will happen
  ## only when the canvas is destroyed. But I keep and add new items (in the
  ## destroyed but kept internally by tk?) canvas. Then on exit, my defined font
  ## will exist :-). A bad situation, but working ok on tk8.4a2 :-)
  proc my_popup {canvas} {
    set menu $canvas.menu
    catch {destroy $menu}
    menu $menu -tearoff 0

    $menu add command -label {Now exit wish and... ????}
    $menu add separator
    $menu add command -label Exit -command exit -background red -foreground white

    tk_popup $menu [winfo pointerx .] [winfo pointery .]
    tkwait window $menu
    destroy $menu
    $canvas delete all
    .x create rectangle 30 30 400 200 -tags rect -fill yellow
    .x create text 220 90 -tags text -text {Click on me to abort :-)} \
                -font MyFont -anchor c
  }

  ############################################################
  ## END
  ############################################################


tkt_uuid: 458790ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Invalid
title: Infinite loop of focus events
comment:
  In what I believe is a fairly typical structure for handling mega-widgets, I get an infinite loop of 
  focus events which, in my particular case, constantly selects the only character in an entry so 
  that you can't type more.  The attached script demonstrates.

  I'm running on UNIX with 8.4a3 (well, a late snapshot of a4, I'm about to get the Real Thing).  
  Bruce Hartweg <brhartweg@bigfoot.com> says this works OK for him "under 98SE with version 
  8.3.3 (from ActiveTcl 8.3.3.2)".


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


tkt_uuid: 458879ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: TIP Implementation
resolution: Fixed
title: Real TIP #26 patch
comment:
  This patch on Tk 8.4a2 implements TIP #26. It has been 
  tested on Linux and Windows, but still needs Mac 
  testing.


tkt_uuid: 459343ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: TIP Implementation
resolution: Accepted
title: TIP#37, grid -uniform, patch
comment:
  This patch implements TIP#37 "Uniform Rows and Columns in Grid".

  This implementation uses Tk_Uid which has been questioned and
  thus needs further discussion.


tkt_uuid: 459835ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Duplicate
title: tk_dialog doesn't respond to button pres
comment:
   tk_dialog .t {Save} {Do you want to save?} {} 0 {Yes}
  {No} 

  When I do this with tk8.4a3, pressing Yes or No doesn't
  seem
  to do anything.  I'm using a SuSE 6.3 KDE 2.0 (mostly
  SuSE 6.4
  compliant) with XFree86 4.0.x.

  Works fine with some version of 8.3.


tkt_uuid: 459895ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Fix for directories that contain spaces
comment:
  As shipped with Tcl/Tk 8.4a3, tk_chooseDirectory in 
  Unix won't enter into directory which names contain
  spaces.


tkt_uuid: 460657ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 55. [focus]
priority: 5 Medium
foundin: None
resolution: Works For Me
title: windows: focus mishandled
comment:
  Tested with itcl 3.1 and wish 8.2 on build 2195 
  of "windows 2000 professional".

  Using tweakui 
  (http://www.microsoft.com/ntworkstation/downloads/Power
  Toys/Networking/NTTweakUI.asp), I've set my windows 
  desktop to not require windows be raised when they get 
  focus.  [Mouse over gives focus to window.]

  Tk violates this -- on mouse over it does one of two 
  things:

  (*) reject focus, or
  (*) raise window to top.

  The first behavior (apparently used when another 
  application has had the focus) is annoying.  The 
  second behavior (apparently used when a window of the 
  Tk application has focus) is seriously horrible.

  For example, error dialogs (ok/ignore/stack trace)
  typically wind up behind the main application window.  
  Under windows, the main application window can't be 
  moved while the error dialog is being displayed.  [The 
  workaround I've found is to use task manager to "kill" 
  the process.  This seems to create a window close 
  event which allows the process to continue from that 
  point -- not great, but perhaps useful during 
  debugging.]


tkt_uuid: 461442ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Make Tk use the default Windows font
comment:
  Hello,

  Donal K. Fellows asked me to submit the following patch I posted to comp.lang.tcl. Its purpose is 
  to make Tk use the standard Windows dialog font by default. In the current version, the default 
  font for Tk buttons, labels, entries etc. is "MS Sans Serif" 8 pt regardless of what font the user 
  configured in Windows; this makes Tk programs look slightly (but noticably) different from native 
  Windows dialog applications. With my patch, Tk uses the Windows standard dialog font by default. 
  Here's the news article I wrote on September 13, 2001.

  --- 8< ---

  To make Tk use the standard Windows dialog font, the Tk
  source code has to be patched in two places. I did this
  for Tk 8.3.3. Perhaps someone has the time to put this
  on a Wiki page, include in a FAQ, or even integrate it
  in the official Tk for Windows source codes.

  First, a few lines have to be added to function TkpGetNativeFont
  in tk/win/tkWinFont.c. These lines add a new font name,
  "windefault", which can be used throughout Tk. The windefault
  font is always the Windows standard dialog font. Note that
  this font is different from all the other system fonts,
  like "system" or "ansi". It has to be implemented differently
  from the other system fonts since it can't be retrieved
  through GetStockObject. Here's the new version of TkpGetNativeFont:

  TkFont *
  TkpGetNativeFont(
      Tk_Window tkwin,/* For display where font will
   be used. */
      CONST char *name)/* Platform-specific font name. */
  {
      int object;
      WinFont *fontPtr;

  /* New code starts here */
  if (strcmp(name,"windefault")==0)
  {
  NONCLIENTMETRICS ncm;
  ncm.cbSize = sizeof(NONCLIENTMETRICS);
  SystemParametersInfo(SPI_GETNONCLIENTMETRICS,
   sizeof(NONCLIENTMETRICS),
  &ncm, 0);

  tkwin = (Tk_Window) ((TkWindow *) 
  tkwin)->mainPtr->winPtr;
  fontPtr = (WinFont *) ckalloc(sizeof(WinFont));
  InitFont(tkwin,
  CreateFontIndirect(&ncm.lfMessageFont),
  0, fontPtr);

  return (TkFont *) fontPtr;
  }
  /* New code ends here - rest of function unchanged */

      object = TkFindStateNum(NULL, NULL, systemMap, name);
      if (object < 0) {
  return NULL;
      }

      tkwin = (Tk_Window) ((TkWindow *) tkwin)->mainPtr->winPtr;
      fontPtr = (WinFont *) ckalloc(sizeof(WinFont));
      InitFont(tkwin, GetStockObject(object), 0, fontPtr);

      return (TkFont *) fontPtr;
  }

  With this modification it's possible to use the new font with any
  Tk widget, like this:

  button .b -text "Whatever" -font windefault

  The second modification sets the windefault font as the default for
  all Tk widgets. This is done by replacing the CTL_FONT define in
  tk/win/tkWinDefault.h with "windefault", like this:

  #define CTL_FONT"windefault"

  In the original version, CTL_FONT is hardcoded to 8 pt MS Sans Serif.

  After these changes, recompile the Tk library and rebuild wish or
  whatever application you're linking Tk into.
  --- 8< ---

  Sorry for not being able to submit CVS diffs, but I think the above should be obvious and not too 
  hard to integrate.

  If you have any questions about this, contact me at wr@grp.de.

  Thanks
  Wolfram Rösler


tkt_uuid: 461760ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Fixed
title: 8.3.x docs: false -message -multiple doc
comment:
  The docs/getOpenFile.n man page for Tk 8.3.1, 8.3.2,
  and 8.3.3, all claim that the commands [tk_get*File]
  support the -multiple and -message options.  That
  is incorrect.  Those options are only available
  in the Tk 8.4 sequence.

  We should backout to revision 1.5 of that file on the 
  core-8-3-1-branch.


tkt_uuid: 461801ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Rejected
title: build under vc++4.0
comment:
  undefined ICON_BIG, ICON_SMALL error

  patch file:tk8.3.3/win/tkWinInt.h. Line 167
  /*
   * Define constants missing from older Win32 SDK header
  files.
   */

  #ifndef WS_EX_TOOLWINDOW
  #define WS_EX_TOOLWINDOW0x00000080L 
  #endif

  +#ifndef ICON_BIG
  +#define ICON_BIG    1
  +#define ICON_SMALL  0
  +#endif


tkt_uuid: 462320ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Release Notes
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: tk/unix/README refers to missing script?
comment:
  the tk/unix/README says:

  There are also a number of visual tests for things such
  as screen layout,
  Postscript generation, etc.  These tests all have to be
  run manually and
  the results have to be verified visually.  To run the
  tests, cd to the
  "tests" directory and run the script "visual".  It will
  present a main
  window with a bunch of menus, which you can use to
  select various tests.

  However, the tests directory contains:

  $ ls
  CVS                clrpick.test      
  macMenu.test       textIndex.test
  README             cmap.tcl          
  macWinMenu.test    textMark.test
  all.tcl            cmds.test         
  macscrollbar.test  textTag.test
  arc.tcl            color.test        
  main.test          textWind.test
  bell.test          config.test       
  menu.test          tk.test
  bevel.tcl          cursor.test       
  menuDraw.test      unixButton.test
  bgerror.test       defs.tcl          
  menubut.test       unixEmbed.test
  bind.test          dialog.test       
  message.test       unixFont.test
  bitmap.test        entry.test        
  msgbox.test        unixMenu.test
  border.test        event.test        
  obj.test           unixSelect.test
  bugs.tcl           filebox.test      
  oldpack.test       unixSend.test
  butGeom.tcl        focus.test        
  option.file1       unixWm.test
  butGeom2.tcl       focusTcl.test     
  option.file2       util.test
  button.test        font.test         
  option.test        visual.test
  canvImg.test       frame.test        
  pack.test          visual_bb.test
  canvPs.test        geometry.test     
  place.test         winButton.test
  canvPsArc.tcl      get.test          
  raise.test         winClipboard.test
  canvPsBmap.tcl     grab.test         
  safe.test          winDialog.test
  canvPsGrph.tcl     grid.test         
  scale.test         winFont.test
  canvPsImg.tcl      id.test           
  scrollbar.test     winMenu.test
  canvPsText.tcl     image.test        
  select.test        winSend.test
  canvRect.test      imgBmap.test      
  send.test          winWm.test
  canvText.test      imgPPM.test       
  spinbox.test       window.test
  canvWind.test      imgPhoto.test     
  text.test          winfo.test
  canvas.test        listbox.test      
  textBTree.test     xmfbox.test
  choosedir.test     macEmbed.test      textDisp.test
  clipboard.test     macFont.test       textImage.test


  Is the "visual" mentioned in the README supposed to be
  "visual.test" or is there a missing script called
  visual?


tkt_uuid: 462338ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Works For Me
title: 20 grid-* tests fail
comment:
  $ cd tk/unix
  $ ./configure --disable-shared
  $ make tktest
  $ ./tktest ../tests/grid.test
  ...
  grid.test:Total140Passed118Skipped2Failed20
  Number of tests skipped for each constraint:
  2nonPortable

  See attached file for failed tests output.

  Perhaps the recent Obj-ification of [grid]
  caused this?


tkt_uuid: 462342ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 50. [pack]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: several pack-* tests fail
comment:
  $ cd tk/unix
  $ ./configure --disable-shared
  $ ./tktest ../tests/oldpack.test
  ...
  Error in startup script: bad option "e": should be top,
  bottom, left, right, expand, fill, fillx, filly, padx,
  pady, or frame
      while executing
  "pack append .pack .pack.violet top .pack.green {left
  e} \
          .pack.blue {left expand} .pack.red {left
  expand}"
      (file "../tests/oldpack.test" line 309)


  Before the evaluation fails complely, with the
  startup script error, several test errors are
  reported, see the attached file.

  Again, these errors are seen on Linux, but not
  Solaris.

  Obj-ification of [pack] ?


tkt_uuid: 462348ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 50. [pack]
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Fixed
title: asymetrical ipadx, ipady broken
comment:
  Before I realized that asymetrical padding was not supported for ipadx and ipady, I tried it:

     % frame .f -relief groove -bd 2 -background red 
     .f
     % pack .f -padx {1c 2c} -pady {5m 10m} -ipadx {10 20} -ipady {36p 72p}
     % pack info .f
     -in . -anchor center -expand 0 -fill none -ipadx 15 -ipady {67 68} -padx {35 71} -pady {18 35}    
  -side top

  Why is ipadx reported  as a single value (and neither of the values I specified) and why is ipady 
  reported as a list of two values when neither seems right?


  When fixing this, please, PLEASE consider just supporting asymetrical internal padding.  Thanks!


tkt_uuid: 462375ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: Inconsistent [grid] error messages
comment:
  On Linux/Alpha, the error messages returned
  by [grid] are inconsistent, apparently
  depending on command execution history:

  $ wish
  % grid x
  can't determine master window
  % grid
  wrong # args: should be "grid option arg ?arg ...?"
  % grid x
  bad argument "x": must be name of window

  This is a new bug, somehow introduced along
  with the Obj-ification of [grid] and [pack].
  I rolled back to the following revisions:

  generic/tkGrid.c1.12
  generic/tkInt.h1.37
  generic/tkPack.c1.7
  generic/tkWindow.c1.34

  and the inconsistency went away.

  This bug is the cause of the 20 failed tests
  previously reported (Tk Bug 462338).

  I do not see this buggy behavior on Solaris.
  I do not yet know why different platforms yield
  different behavior.


tkt_uuid: 462629ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Duplicate
title: event generate ButtonPress-2
comment:
  After generating a ButtonPress-2 event, whenever I move
  within an entry widget there is an error:
  Error: can't read "tkPriv(x)": no such element in array

  The stack trace is:
  can't read "tkPriv(x)": no such element in array
      while executing
  "if {abs(145-$tkPriv(x)) > 2} {
              set tkPriv(mouseMoved) 1
          }"
      invoked from within
  "if {!$tk_strictMotif} {
          if {abs(145-$tkPriv(x)) > 2} {
              set tkPriv(mouseMoved) 1
          }
          .test scan dragto 145
      }
  "
      (command bound to event)

  The following script shows the problem on tcl 8.3.3,
  linux 2.4... Hit the Event button and move the pointer
  within the entry widget and the error will appear.

  proc Event {} {
      # Adding this line causes the 
      event generate . <ButtonPress-2> -x 0 -y 0
  }

  proc SetUp {} {
      button .event -text Event -command Event
      button .exit -text Exit -command exit

      entry .test
      grid .test .event .exit
  }

  SetUp


tkt_uuid: 463234ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Fix 'Windows button height
comment:
  This patch makes text buttons on 'Windows the right height.  The 
  results are entirely empirical; I have no technical reference that leads 
  me to believe this is "correct" code.  However, on NT and W98, 
  creating a button with the correct font, gives a button whose height 
  matches native buttons.

  This patch was created with

      diff -patch ourlocalfile  mychangedfile >thefile.patch

  so it may or may not be quite the right format.  It includes changes to 
  tkWinButton.c and tkWinDefault.h.


tkt_uuid: 464451ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 6
foundin: obsolete: 8.4a5
resolution: Fixed
title: '$menu post' posts menu in wrong position.
comment:
  Under some circumstances, a tk_optionMenu can post its 
  menu largely offscreen.  I've observed the problem 
  both with single and multi-column menus, but have only 
  been able to make a simple, reproducible example with 
  multi-column menus.

  The following script shows how to achieve this:

  >wish84

  % eval tk_optionMenu .om enc [lsort [encoding names]]
  .om.menu
  % pack .om
  % .om.menu entryconfigure 45 -columnbreak 1

  Now, drag '.' to somewhere close to the top of the 
  screen (my screen is 780 pixels tall, for reference), 
  or at least in the top quarter.

  Now, use the option menu and select an item towards 
  the end of the menu (e.g. "unicode" in the menu 
  constructed above).  

  Now try using the option menu a second time.  It posts 
  almost completely off the bottom of the screen, 
  nowhere near the menu-button itself!

  (The above works on Win2000 sp2, at least, but the 
  problem appears to be in tk's 'menu.tcl' file which 
  controls menu posting)


tkt_uuid: 465269ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: Invalid
title: DoubleClickEvent at CanvasWindowItem
comment:
  The DoubleClick doesn't work correctly with the Canvas
  Window Item. It executes twice a SingleClick.
  The window Item includes a label-widget.


tkt_uuid: 465324ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 8
foundin: obsolete: 8.4.1
resolution: Fixed
title: menu clones are not deleted
comment:
  The following simple script adds a menubar to the '.' 
  window and then repeatedly adds and removes a 
  submenu.  The result of this is that some 10 clone 
  menus (and their '.#menubar...' commands) are left 
  around, consuming memory and resources.

  catch {console show}

  menu .menubar
  . configure -menu .menubar
  menu .menubar.test

  for {set i 0} {$i < 10} {incr i} {
      .menubar add cascade -menu .menubar.test \
        -label "Test"
      .menubar delete Test
  }

  puts "info commands .#menubar*test*"
  puts [info commands .#menubar*test*]


  (Tested on 8.3.2 and 8.4a4 on Windows2000 sp2)


tkt_uuid: 465761ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 7 High
foundin: obsolete: 8.4a4
resolution: Fixed
title: [exit] does not exit bg wish
comment:
  $ cat test.tcl
  exit
  $ wish test.tcl &
  [3] 5087
  $ 
  [3]  + Suspended (tty output)        wish test.tcl


  Note that the wish process is left "Suspended",
  not "Terminated".

  This problem is apparently new since 8.4a2.

  It only shows up in wish, not in tclsh.

  As is, a 'kill' is needed to terminate the
  wish process.


tkt_uuid: 466773ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Invalid
title: Checkbuttons look wrong when activated
comment:
  In Windows Me with Tcl/Tk 8.3.3, checkbuttons keep a
  grey background when activated, they don't change it to
  white
  until they get a <Leave> event.


tkt_uuid: 468139ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Improved tk_chooseDirectory on Windows
comment:
  The tk_chooseDirectory in the current and past Tk 
  versions on windows uses the built-in windows 3.1 
  style directory browse. This browser has many 
  shortcomings including inability to select network 
  shares via UNC names, returns all names in uppercase 
  and generaly appears klunky and outdated. The attached 
  patch, when applied to the latest Tk 1.21 
  tkWinDialog.c will add the newer windows directory 
  browser. You can still go back to the old version by 
  #defining USE_OLD_CHOOSEDIR. Hopefully, if test goes 
  well the code for the old browser can later be removed.
  Worked based on initial Jeff Hobbs code and modified 
  by Tom Wilkason (tom.wilkason@home.com).


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


tkt_uuid: 469670ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: Fixed
title: tk_get*File doesn't filter w/ motif
comment:
  When tk_strictMotif is set, tk_getOpenFile and tk_getSave file fail to filter if more than one pattern 
  is provided for a filetype.

  For example:

  With a .o file in the current directory:

     tk_getOpenFile -filetypes {{"Foo" {.f .o}} {"Bar" {.b .p}} {"Tcl" {.tcl}}}

  will show no files to choose from.

  xmfbox.tcl was missing a foreach to iterate over patterns in the filter spec.  The foreach was in 
  tkfbox.tcl.


tkt_uuid: 469752ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 05. Canvas Items
priority: 4
foundin: None
resolution: Postponed
title: Rotated text patch for canvas
comment:
  This patch, which is designed to apply to Perl/Tk
  800.023, adds rotated text support in canvases to X11
  and Postscript output, with no support for WIndows or
  Mac.  The postscript output is correct; the X11 display
  is somewhat klugy.  The rotation is specified with the
  -angle option, in degrees counterclockwise.

  See the original post at
  http://groups.google.com/groups?selm=9ok2mi%249qg%241%40decurion.mit.edu

  This patch definitely needs more work, but akupries
  suggested that I upload it anyway "so it won't get
  lost", and I am doing that.


tkt_uuid: 470322ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: Fixed
title: Tk_GetBitmapFromData broken
comment:
  The now obsolete function Tk_GetBitmapFromData, if
  used, will corrupt the bitmap hashtable causing much
  grief later on...  This problem appears to be present
  in 8.4 as well.

  To put your mind at ease, after fixing this bug in Tk,
  I then went into my code and removed 
  Tk_GetBitmapFromData, replacing it with
  Tk_DefineBitmap.  If you don't fix the bug, then remove
  the function altogether.

  Thanks,
  -Brian

  P.S.
  The attaced partially fixes the problem, however, I
  still get a crash in my application.  I did not track
  it down since I have since changed the implementation
  to use DefineBitmap instead.


tkt_uuid: 470331ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.5.4
resolution: Accepted
title: Displaced Menus do not stay open.
comment:
  When
  a) a menubutton is near the lower edge of the screen
  b) the user tries to open the menu with a simple click
     (and immediately releases the mouse button)
  c) the menu is too long to be displayed in full
  length     on the remaining screen space and is
  displaced:

  the menu will immediately disappear again, selecting
  an entry that is under the mouse pointer after
  displacement. The user has no chance to select, nor
  does he even see what he selected. Anything including
  some really evil things like deleting files etc. can
  happen.

  Expected behaviour:
  The menu should simply stay open as it is doing
  when it does not need to be displaced.

  Note: On Windows this works as expected!
  No test has been performed on the Mac.
  Xaw(3D) does it wrong too, Motif/GTK do it right
  but displace in a different way.

  Sample Script:
  Run it. Place the window on the lower edge of your
  screen. Do a single click on "File". The application
  quits unexpectedly...

  -snip-
  # Create a menubar 
  # 
  menu .mb -type menubar 
  . config -menu .mb 
  .mb add cascade -label File -underline 0 -menu .mb.file 
  menu .mb.file -tearoff 0 
  .mb.file add command -label Exit -command exit 
  .mb.file add command -label Exit -command exit 
  .mb.file add command -label Exit -command exit 
  .mb.file add command -label Exit -command exit 
  .mb.file add command -label Exit -command exit 
  .mb.file add command -label Exit -command exit 
  .mb.file add command -label Exit -command exit 
  .mb.file add command -label Exit -command exit 
  .mb.file add command -label Exit -command exit 
  .mb.file add command -label Exit -command exit 
  .mb.file add command -label Exit -command exit 

  frame .f -width 200 -height 100 
  pack .f -side top -fill both -expand 1 
  update 
  -snap-


tkt_uuid: 470560ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: TIP Implementation
resolution: Accepted
title: tip 63 patch
comment:
  This patch has been tested by maintainers on win, 
  unix, macos and it works fine.  Since the tip has been 
  accepted, could someone apply it to the core.


tkt_uuid: 471727ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: TIP Implementation
resolution: Rejected
title: TIP 64 - Expose system, desktop fonts
comment:
  A follow-up to patch 461442 which was created by "nobody".

  This patch exposes all the fonts configurable in the 'Windows desktop 
  properties sheet as well as "defaultgui" which should be used for most
  user interface elements.  

  This patch does NOT (yet) address dynamic reconfiguration of fonts as
  described in the TIP.


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

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

  should be

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


tkt_uuid: 472250ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: tkConfig.sh not in MacOSXTk8.4a4.tar.gz
comment:
  In the Mac OS X build available on tcl.sourceforge.net 
  (MacOSXTk8.4a4.tar.gz), tkConfig.sh is missingin the TK 
  framework, although tclConfig.sh is available in TCL 
  framework.

  Please deliver this vital piece for anyone wishing (!) to use 
  Tk libs on Mac OS X.

  Thanks,
  Rupert


tkt_uuid: 472276ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Invalid
title: disable text selection bug on Windows
comment:
  Text selection in disabled (readonly) text widgets is
  not visible on Windows (unlike X11), even though it is
  selected.  You can duplicate this bug with the enclosed
  wish script.

  Greg Couch
  gregc@cgl.ucsf.edu
  -------
  #!/usr/bin/env wish

  text .text -exportselection 0 -takefocus 1
  .text insert 1.0 "some maybe selectable text\n"
  .text insert 2.0 "tcl$tcl_patchLevel tk$tk_patchLevel"
  .text tag add sel 1.0 end
  .text config -state disabled
  bind .text "<ButtonRelease-1>" {puts "[.text tag ranges
  sel]"}
  pack .text

  button .b1 -text Enable -command {.text config -state
  normal}
  pack .b1
  button .b2 -text Disable -command {.text config -state
  disabled}
  pack .b2


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


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

  can me anybody explain what is wrong?

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

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

  Thank for comment.

  Michal, mmestan@iol.cz


tkt_uuid: 473944ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: tk_chooseDirectory causes bus error on M
comment:
  tk_chooseDirectory causes bus error on Mac OS X v10.1.


  Other file dialog commands (tk_getOpenFile and 
  tk_getSaveFile) work fine.

  Here is the sample script to reproduce the problem.

  #!/bin/sh
  # the next line restarts using wish \
  exec ~/Wish\ Shell.app/Contents/MacOS/Wish\ Shell "$0" 
  "$@"
  button .b1 -text choose_directory -command {
       tk_chooseDirectory -title "Choose directory"
  }
  button .b2 -text exit -command exit
  pack .b1 .b2


tkt_uuid: 474151ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: None
resolution: Works For Me
title: Clicking on menubar crashes wish
comment:
  I'm using tkcon with wish from CVS. When tkcon comes
  up, the menubar is all messed up. This doesn't occur
  with wish8.3. That's a first issue. But then, if I
  click on the menu bar, wish crashes with this error
  message:

  Tk_FreeGC received unknown gc argument
  Abort

  I'm attaching a snapshot of the window when tkcon first
  comes up.

  L


tkt_uuid: 475332ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 25. Built-in Bitmaps
priority: 5 Medium
foundin: None
resolution: None
title: Provide new bitmaps, introspection
comment:
  I'm submitting a TIP to provide more bitmaps and a means to list built-in bitmaps.
  This patch contains the reference implementation.


tkt_uuid: 476176ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 4
foundin: None
resolution: Fixed
title: wish core dump with frame -container on
comment:
  From: David Gravereaux <davygrvy@pobox.com>
  Newsgroups: comp.lang.tcl
  Subject: Re: wish core dump with frame -container on NT

  pat@porky.home.net (Pat Thoyts) wrote:
          
  >Ralf Fassel <ralfixx@gmx.de> wrote:
  >>Can anybody confirm this with wish on Windows NT:
  >>
  >>    $ wish
  >>    % frame .f -container 1
  >>    % exit
  >>    Segmentation fault (core dumped)
  >>
  >>This is with cygnus tcl/tk 8.0 and a customized wish
  8.3.3.
  >>Unfortunately I don't have a plain windows wish
  installed.
  >>
  >>R'
  >
  >Well I can confirm that this crashes on Windows 98
  with Tcl and Tk
  >8.3.4. As I havn't built the debug version yet I don't
  have any
  >more info. l8r

  here's the fix for it.  Please post this into the
  sourceforge BugDB.  I'm not
  much for following-up on bugs I don't consider my own,
  sorry..


  Index: tkWinEmbed.c
  ===================================================================
  RCS file: /cvsroot/tktoolkit/tk/win/tkWinEmbed.c,v
  retrieving revision 1.4
  diff -c -r1.4 tkWinEmbed.c
  *** tkWinEmbed.c        2000/07/06 03:17:44     1.4
  --- tkWinEmbed.c        2001/10/27 09:43:53
  ***************
  *** 632,637 ****
  --- 632,638 ----

        prevPtr = NULL;
        containerPtr = tsdPtr->firstContainerPtr;
  +     if (containerPtr == NULL) return;
        while (1) {
          if (containerPtr->embeddedPtr == winPtr) {
              containerPtr->embeddedHWnd = NULL;


  --
  David Gravereaux <davygrvy@pobox.com>

  $ make war
  make: *** No rule to make target `war'.  Stop.  Try
  `love' instead.


tkt_uuid: 477740ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 6
foundin: obsolete: 8.4a4
resolution: Fixed
title: Incorrect display of disabled compound buttons
comment:
  Wish seems to crash on my system (windows XP but
  probably under all windows versions)
  when a button is displayed the is in the disabled
  state and has both an image + text with the
  -compound option set to other than none.
  This bug does not exist under unix and seems
  to exist in the latest CVS sources (tk8.4a4).

  A simple script to reproduce the bug is:

  image create photo empty -width 24 -height 24
  pack [button .b -text {Crash Tk} -image empty \
                  -compound left -state disabled \
                  -command exit]

  After doing a little debugging, it seems that
  the gc used to draw the message does not has
  a valid font (fontptr == NULL). Perhaps a
  problem during the configuration of the button?
  What follows is the stack trace:

  MultiFontTextOut(HDC__ * 0x5001086c, WinFont * 
  0x00000000, const char * 0x00c5d508, int 8, int 32, 
  int 24) line 948 + 3 bytes
  Tk_DrawChars(_XDisplay * 0x00af4d60, unsigned long 
  12210792, XGCValues * 0x00c1b6b0, Tk_Font_ * 
  0x00c18f08, const char * 0x00c5d508, int 8, int 32, 
  int 24) line 883 + 29 bytes
  Tk_DrawTextLayout(_XDisplay * 0x00af4d60, unsigned 
  long 12210792, XGCValues * 0x00c1b6b0, Tk_TextLayout_ 
  * 0x00c1bb08, int 32, int 11, int 0, int 100000000) 
  line 2198 + 57 bytes
  TkpDisplayButton(int * 0x00c18bb0) line 520 + 48 bytes
  TclServiceIdle() line 692 + 12 bytes


tkt_uuid: 477949ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 57. [option]
priority: 5 Medium
foundin: obsolete: 8.4a1
resolution: None
title: option readfile cannot use multibytes
comment:
  since 'option readfile' doesn't convert encodings
  of the target resource file,
  multibyte characters in such resource files
  (mainly for Japanese TrueType font name on MS-win32)
  are not interpretted correctly.

  on MS-Win32 environment, I wrote a resource file:

  *Label*Font: {Times New Roman} 40 normal

  goes well, but when I use Japanese TrueType font
  names replacing above 'Times New Roman',
  the font is not loaded, and the output of
  [.label cget -font] is in some binary(unreadable)
  characters.


tkt_uuid: 477955ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 76. Widget Tour
priority: 2
foundin: None
resolution: Fixed
title: Some little missspell in demos...
comment:
  Hi,

  I post sam little mistakes in demos...

  File
  tk/library/demos/Dilaog2.tcl:                                                           
                                                                                               
  set i [tk_dialog .dialog2 "Dialog with local grab"
  {This dialog ...                          
                                                                                               
  may
  be                                                                                       
                                                                                               
  set i [tk_dialog .dialog2 "Dialog with global grab"
  {This dialog ...                         
                                                                                               
                                                                                               
                                                                                               
                                                                                               
  In
  files                                                                                     
  tk/library/demos/rolodex                                                                     
  tk/library/demos/ixset                                                                       
  tk/library/demos/browse                                                                      
                                                                                               
  after install things as
  below:                                                               
                                                                                               
  #!/bin/sh                                                                                    
  # the next line restarts using wish
  \                                                        
  exec wish8.48.4 "$0" ${1+"$@"} || exec wish "$0"
  ${1+"$@"}                                   
                                                                                               
  and in
  CVS:                                                                                   
                                                                                               
  #!/bin/sh                                                                                    
  # the next line restarts using wish
  \                                                        
  exec wish8.4 "$0" ${1+"$@"} || exec wish "$0"
  ${1+"$@"}                                      
                                                                                               
  After instaling are appended another
  "8.4".                                                  
  (onother demos have only exec wish "$0" ${1+"$@"})

  Michal wohnivec@iol.cz


tkt_uuid: 478498ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 34. [tk_chooseColor]
priority: 5 Medium
foundin: None
resolution: Fixed
title: sliders to allow full range selection
comment:
  in tk_chooseColor for unix, the color sliders are 128
  pixels wide, and effectively only allow the user to
  choose even numbers. This would ordinarily not be
  noticeable, but at the end of the range, sometimes you
  want to be able to choose 255 for maximum intensity.

  To fix this, find the line in clrpick.tcl which reads
  "set data(BARS_WIDTH) 128", and change the 128 to a
  256. This will have the effect of making the color
  chooser window wider, but I don't think that it can be
  considered any sort of drawback.


tkt_uuid: 478568ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 6
foundin: obsolete: 8.5a0
resolution: Fixed
title: problems displaying some italic fonts
comment:
  This may be a windows-specific problem, and might be 
  the same as bug 220086, or at least related.

  I'm seeing this bug on Win2K, with the most recent 
  versions of 8.2, 8.3 and 8.4. I do *NOT* see this 
  problem with 8.0.5.

  The nutshell summary is that if I configure a text tag 
  to have a slant of italic but all other font metrics 
  identical to other text, and the family is {MS Sans 
  Serif}, I get extra visual whitespace between the 
  italic and non-italic text. And if I move the 
  insertion cursor through the italicized text (using 
  arrow keys, for example) the whitespace shifts around. 

  It's almost as if the physical x location of non-
  italic characters and the insertion cursor is based on 
  a different font metric than that used to compute the 
  physical x location of the italic characters.  

  As I've said, this happens with {MS Sans Serif}. It 
  also seems to happen with "Fixedsys" I've tested with 
  a family of "Helvetica" and with "Arial" 
  and "Microsoft Sans Serif" and the problem goes away, 
  so it's somewhat font-specific. I didn't have the 
  patience to try every font on my system, but would be 
  willing to do so if called upon.

  I wouldn't make a big deal about this, and chalk it up 
  to Microsoft nonsense, but the problem doesn't exist 
  in 8.0.5 so it appears to be a regression on the part 
  of tk.

  Also, considering the default font for text widgets on 
  windows (at least on my box) is {MS Sans Serif}, this 
  should probably be addressed. Either fix the bug or 
  pick a better default font (Arial? Personally I vote 
  for Verdana, but I don't know how ubiquitous it is 
  yet).

  Here's a script you can use to see the problem:

  pack [text .t]
  eval font create romanFont [font actual [.t cget -
  font]]
  eval font create italicFont [font actual [.t cget -
  font]]

  font configure italicFont -slant italic -family {MS 
  Sans Serif}
  font configure romanFont  -slant roman -family {MS 
  Sans Serif}

  .t tag configure italic -font italicFont
  .t tag configure roman  -font romanFont

  .t insert 1.0 "this is italic" italic " and this is 
  not." roman


tkt_uuid: 479098ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: None
resolution: Invalid
title: latest tk from cvs crashes w/tkchat
comment:
  Platform: SPARC Solaris 2.6 Sun compiler and tcl/tk
  8.4a4 from nov 5 snapshot tar file of andreas kupries.

  attempts to invoke tkchat (from the tcllib project)
  results in the error:
  Tk_FreeGC received unknown gc argument
  Abort(coredump)
  when hitting the update idletasks in errLog .  The
  stack for this is:

  $ dbx $(whence wish8.4) core
  Reading wish8.4
  core file header read successfully
  Reading ld.so.1
  Reading libtk8.4.so
  Reading libtcl8.4.so
  Reading libsocket.so.1
  Reading libnsl.so.1
  Reading libX11.so.4
  Reading libdl.so.1
  Reading libm.so.1
  Reading libc.so.1
  Reading libmp.so.2
  Reading libXext.so.0
  Reading libdga.so.1
  Reading libc_psr.so.1
  program terminated by signal ABRT (Abort)
  (dbx 1)
  where                                                  
  =>[1] _kill(0x0, 0x6, 0x0, 0xffffffff, 0xfef3c404,
  0xfeeb5690), at 0xfef1ba28
    [2] abort(0xfef3800c, 0xffbebc20, 0xff22f57c, 0x0,
  0x1, 0x8), at 0xfeeb5774
    [3] Tcl_Panic(0xff340a80, 0x20, 0x0, 0x20,
  0xffbebbcc, 0x39580), at 0xff1f4348
    [4] Tk_FreeGC(0x0, 0x20, 0xff3564c8, 0x120c20,
  0x1181b0, 0x1181b0), at 0xff2b5db8
    [5] TkMenuConfigureEntryDrawOptions(0x0, 0x0, 0x0,
  0x0, 0x0, 0x120ea0), at 0xff2f3cf4
    [6] MenuWorldChanged(0x1, 0x0, 0x117a90, 0x0, 0x0,
  0x0), at 0xff2efe6c
    [7] RecomputeWidgets(0x1181b0, 0xff3564c8, 0x2f928,
  0x4c6a8, 0x0, 0x0), at 0xff2b179c
    [8] RecomputeWidgets(0x1181b0, 0xff3564c8, 0x314,
  0xff374b68, 0x223d8, 0xff203e8c), at 0xff2b17b4
    [9] TclServiceIdle(0x0, 0x1, 0x2cf18, 0x13e9b0, 0x0,
  0x0), at 0xff203e84
    [10] Tcl_DoOneEvent(0x0, 0xff22f57c, 0x22c90, 0x0,
  0x22ca8, 0x1), at 0xff1f269c
    [11] MapFrame(0x4c6a8, 0x4c6a8, 0xff22f57c,
  0xff3903a4, 0xff3e2628, 0xff286fd1), at 0xff2ea724
    [12] TclServiceIdle(0x0, 0x0, 0x2cf18, 0x30550,
  0x13ec20, 0x0), at 0xff203e84
    [13] Tcl_DoOneEvent(0x0, 0x13fdb0, 0x22c90, 0x0,
  0x22ca8, 0x1), at 0xff1f269c
    [14] Tk_UpdateObjCmd(0x2f928, 0x20, 0x2, 0x23c48,
  0x22fe0, 0x22fe0), at 0xff2a97f8
    [15] TclExecuteByteCode(0x23c48, 0xff22f57c,
  0x142d0d, 0x2, 0xc, 0x23c38), at 0xff1ca0f8
    [16] Tcl_EvalObjEx(0xff235df4, 0x0, 0xffbec53c,
  0xff22f57c, 0x1912, 0x22fe0), at 0xff1a6f28
    [17] TclObjInterpProc(0xff21ecc8, 0x4, 0xf3938,
  0xffbec2bc, 0xff22f57c, 0x1), at 0xff1fda34
    [18] TclExecuteByteCode(0x23c40, 0xff22f57c,
  0x1427a1, 0x2, 0x4, 0x23c38), at 0xff1ca0f8
    [19] Tcl_EvalObjEx(0xff235df4, 0x0, 0xffbeca34,
  0xff22f57c, 0x190f, 0x22fe0), at 0xff1a6f28
    [20] TclObjInterpProc(0x1, 0x23b40, 0x10d978,
  0xffbec7b4, 0xff22f57c, 0x0), at 0xff1fda34
    [21] TclExecuteByteCode(0x23c3c, 0xff22f57c,
  0x115a8d, 0x1, 0x0, 0x23c38), at 0xff1ca0f8
    [22] Tcl_EvalObjEx(0xff235df4, 0x0, 0xffbecf2c,
  0xff22f57c, 0x176e, 0x22fe0), at 0xff1a6f28
    [23] TclObjInterpProc(0x6, 0x108e08, 0xdf3c8,
  0xffbeccac, 0xff22f57c, 0x0), at 0xff1fda34
    [24] TclExecuteByteCode(0x23c38, 0xff22f57c,
  0x113f3a, 0x1, 0x0, 0x23c38), at 0xff1ca0f8
    [25] Tcl_EvalObjEx(0x0, 0x0, 0x0, 0xff22f57c, 0x176d,
  0x22fe0), at 0xff1a6f28
    [26] Tcl_IfObjCmd(0x3, 0xff21c4d0, 0x4, 0xffbed3f0,
  0xff21c4c8, 0x0), at 0xff1aead4
    [27] EvalObjv(0x26110, 0x0, 0xb4358, 0x0, 0x0, 0x0),
  at 0xff1f5058
    [28] Tcl_EvalEx(0x22fe0, 0xffbed3f0, 0x1, 0x0,
  0xb4358, 0x34), at 0xff1f5804
    [29] Tcl_FSEvalFile(0x4ca70, 0x0, 0x4bdb8,
  0xff22f57c, 0x1, 0x4be48), at 0xff1e7bac
    [30] Tcl_EvalFile(0x22fe0, 0x4be48, 0x0, 0xff367a00,
  0x1, 0xff3679ec), at 0xff1e6f40
    [31] Tk_MainEx(0xff3679d4, 0x2b260, 0xffbed6f8,
  0x22fe0, 0xff3564c8, 0x10c04), at 0xff2bc7b0
    [32] main(0x2, 0xffbed884, 0x2, 0x20d90, 0x0, 0x0),
  at 0x10be4
  (dbx 2) 


tkt_uuid: 480158ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 55. [focus]
priority: 5 Medium
foundin: final: 8.2.3
resolution: None
title: initial focus fails in child interp
comment:
  I was trying to create a child interpreter which could
  create a set of widgets and embed that within a frame
  in the main interpreter.  Most widgets work fine but
  anything that depends on getting focus won't work
  reliably on different platforms or with different
  window managers.

  To reproduce, create an interp within the main
  interpreter and create a Tk text widget within the
  child.  It is difficult to get the text widget to take
  the focus by clicking.  This means that the "I" cursor
  does not get inserted and the black line indicating
  that the text area is ready for editing does not
  appear.  I played around with varying configurations
  including packing and depth within the window hierarchy
  with different results.  

  The following example always failed for me on Windows
  2000 but seemed to work more often on Solaris using
  CDE.  

  interp create child
  toplevel .t
  frame .t.f -container 1
  pack .t.f -fill both -expand yes
  interp eval child "lappend argv -use [winfo id .t.f]"
  interp eval child {
      load {} Tk
      text .text
      pack .text -fill both -expand yes
  }


tkt_uuid: 480836ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Invalid
title: tk::MenuDup not found while using menus
comment:
  The following script generates an error with Tk
  from the CVS. It worked just fine in earlier versions.
  It is likely this broke as a result of TIP 44. Are
  there any test cases in the test suite that cover
  this?


tkt_uuid: 480862ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 40. Bitmap Images
priority: 7 High
foundin: obsolete: 8.4a4
resolution: Fixed
title: UNIX Ignores Bitmap Changes
comment:
  If I create a bitmap image with some image data,
  display it, and then reconfigure it to have some
  different data (see the example code below) then this
  change in the data is not displayed *on UNIX/X only*.
  This works correctly on Windows (though it is slow as
  the size of the bitmap increases...)

  set e {#define empty_width 4
  #define empty_height 4
  static char empty_bits[] = {
     0x00, 0x00, 0x00, 0x00};}
  set f {#define full_width 4
  #define full_height 4
  static char full_bits[] = {
     0x0f, 0x0f, 0x0f, 0x0f};}
  image create bitmap b -data $e
  pack [label .l -image b]
  after 3000 {b configure -data $f}

  I originally noticed the problem using the script
  http://www.cs.man.ac.uk/~fellowsd/tcl/bitsandpieces/bitmap.tcl
  (recombine URL?)


tkt_uuid: 480944ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: -- New Commands
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Add console support to Tk / Unix
comment:
  Could something at least equivalent to the Windows/Mac
  Tk code - and perhaps as nice as tkcon - please be
  added to the standard Tk app.  Otherwise, windows and
  mac programmers are faced with conditional programming
  around this currently non-cross-platform command.

  In fact, tcl and tk should make it clearer when
  something is not cross platform.  The doc doesn't
  mention that it isn't available on all platforms. 
  Perhaps if console is not to be supported on Unix, it
  should at least be moved into a package that must be
  require'd to use?  But the preference would be for it
  to be available on all platforms.


tkt_uuid: 481148ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: None
resolution: Accepted
title: add [wm stackorder] command
comment:
  The attached patch is the first draft of a
  wm stackorder command. It should not be applied
  in its current form. A TIP describing this
  command will be added shortly.


tkt_uuid: 481219ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: Fixed
title: Cascaded menus and arrow keys
comment:
  There is hard to use arrow keys in cascaded menus 
  (X11 environment). For example, run standard tk 
  demos, choose "Menus and cascades" and try to reach
  "Cascades"/"Radio buttons" submenu using arrow keys. 
  I can't.

  After applying attached patch, X11 menus works like 
  Windows menus.


tkt_uuid: 481255ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Fixed
title: palette 2 doesn't work for windows
comment:
  When you want to create a black and white photo using the -palette 2 option, you got a corrupted image.

  But -palette 1 and -palette 3 work for windows and -palette 2 works for linux.


tkt_uuid: 481308ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 32. Key Symbols
priority: 8
foundin: None
resolution: None
title: Fix for Bug 229038 numerals pad solaris
comment:
  on Sun Solaris machines the numerals pad generates
  problems when there is a bind on the arrow-keys.
  In en entry-widget, the 4 and 6 numerals dont work, in
  a text-widget the 4,6,2 and 8 numerals.
  The problem is, that the "Numlock-Key" has the same
  effect as the "Mode-Key", but affects only the keys of
  the numerals pad. As a consequence, the third or fourth
  slot of the keymap-vector must be used, not the first
  and second. 
  When the first two vectors are used, XKeycodeToKeysym
  always produces the keysyms for the arrow key's and
  then the binding of the arrow-keys is taken and not the
  numeral istself.
  When there is no bind on the arrow-keys, the keys of
  the numerals pad work fine, because the function
  XmbLookupString takes the keycode and the state of the
  mode-switches.
  I tested my patch on a sun solaris machine with solaris
  2.7.
  I hope it works also with linux.
  I attach a patch for the following files
  generic/tkInt.hVersion 1.40
  unix/tkUnixKey.cVersion 1.5


tkt_uuid: 482139ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: Out of Date
title: MacOS: menus broken in some cases
comment:
  The provided script shows an error case of menu display
  on Mac platforms.  The script needs BWidget (actually,
  the BWidget MainFrame).

  Observed on: Tcl/Tk 8.3.3, MacOS 9.1

  Observed behaviour : The menu entries do not get drawn
  correctly, they are misplaced. Additionally, the Mac
  *system* menu is also broken (misplaced). See the
  comments in the script for more detail.

  Bastien


tkt_uuid: 483387ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 6
foundin: obsolete: 8.3.2
resolution: None
title: BadFont error using multiple X servers
comment:
  The script below documents and demonstrates the
  problem.  I've worked around this in my environment, so
  it isn't urgent for me, but it would be nice if it
  could be fixed or documented as a limitation.

  Ken Fitch


  #
  #       This tk/tcl script demonstrates the X BadFont
  error thrown when
  #       we set up a toplevel for display on an X server
  that is different
  #       from the X server derived from "-display" or
  the 
  #       DISPLAY environment
  #       variable.
  #
  #       Using multiple screens on a single X server
  host seems to be OK
  #               
  #       This problem was seen on a Solaris system
  running Tk/Tcl 8.3.2
  #
  #       To test on your system:
  #       
  #               - you need X server access to some
  other machine on your  
  #                 network
  #
  #               - invoke as "wish <this script>"
  #                       (it should exit normally)
  #
  #               - invoke as "wish <this script>
  -display  <remote_X_server>:0.0"
  #                       (it should throw a BadFont
  error)
  #       
  #       Alternatively, you can edit the X_screen line
  to use a remote X server
  #       and omit the "-display" stuff.  The key is to
  get the "." window and the
  #       ".my_toplevel" windows to be rendered on
  different hosts.
  #
  ##################################################################################
  #
  #       I'm not sure if there's an easy (or hard) fix
  for this or not.  This does 
  #       not seem to me to be a common case, so it may
  be sufficient to simply
  #       document the behavior.  I have no idea what
  would happen on a non-Unix system.
  #
  #       It would be nice if the code could detect the
  situation, and at least 
  #       circumvent the X error(s).
  #
  #


  set X_screen ":0.0"


  eval font create symbolic_font 

  set window  [toplevel .my_toplevel -screen $X_screen] 
  button $window.button  -text "Touch here"  -font
  symbolic_font



  puts "default     window screen: [winfo screen .]"
  puts "my_toplevel window screen: [winfo screen
  .my_toplevel]"

  puts "about to delete named font symbolic_font ..."
  font delete symbolic_font 
  update

  puts "about to create named font symbolic_font ..."
  font create symbolic_font 
  update
  puts "taking a nap ..."
  after 3000
  puts "exiting normally"
  exit


tkt_uuid: 483832ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 4
foundin: obsolete: 8.4a4
resolution: Wont Fix
title: clipboard.test failure
comment:
  I am seeing the following failure when running the test
  suite with the latest Tk on SPARC Sun Solaris 2.6 and
  Sun's compiler and CDE window manager.

  ==== clipboard-6.2 Tk_ClipboardAppend procedure FAILED
  ==== Contents of test case:

      setupbg
      clipboard clear
      clipboard append -f INTEGER -t TEST "16"
      set result [dobg {clipboard get TEST}]
      cleanupbg
      set result

  ---- Result was:
  CLIPBOARD selection doesn't exist or form "TEST" not
  defined
  ---- Result should have been:
  0x10
  ==== clipboard-6.2 FAILED


tkt_uuid: 483833ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Duplicate
title: event.test event-click-drag-1.2 fails
comment:
  sparc/solaris 2.6/sun c compiler/cde window manager

  latest tk from cvs fails this test suite test:
  event.test

  ==== event-click-drag-1.2  click and drag in an entry
  widget, this
                              tests tkEntryMouseSelect in
  entry.tcl  FAILED
  ==== Contents of test case:

      destroy .t
      set t [toplevel .t]
      set e [entry $t.e]
      pack $e
      tkwait visibility $e
      focus -force $e
      _keypress_string $e "A Tcl/Tk selection test!"
      set anchor 6
      set selend 18

      set result [list [$e get]]

      # Get the x,y coords of the second T in "Tcl/Tk"
      foreach {anchor_x anchor_y} [_text_ind_to_x_y $e
  $anchor] break

      # Click down to set the insert cursor position
      event generate $e <Enter>
      event generate $e <ButtonPress-1> -x $anchor_x -y
  $anchor_y

      # Save the position of the insert cursor
      lappend result [$e index insert]
      
      # Now drag until selend is highlighted, then click
  up

      set current $anchor
      while {$current <= $selend} {
          foreach {current_x current_y} [_text_ind_to_x_y
  $e $current] break
          event generate $e <B1-Motion> -x $current_x -y
  $current_y
          incr current
          _pause 50
      }

      event generate $e <ButtonRelease-1> -x $current_x
  -y $current_y
      _pause 200
      # Save the position of the insert cursor
      lappend result [$e index insert]

      # Save the highlighted text
      lappend result [selection get]

      # Now click and click and drag to the left, over
  "Tcl/Tk selection"

      event generate $e <ButtonPress-1> -x $current_x -y
  $current_y

      while {$current >= ($anchor - 4)} {
          foreach {current_x current_y} [_text_ind_to_x_y
  $e $current] break
          event generate $e <B1-Motion> -x $current_x -y
  $current_y
          incr current -1
          _pause 50
      }

      event generate $e <ButtonRelease-1> -x $current_x
  -y $current_y
      _pause 200

      # Save the position of the insert cursor
      lappend result [$e index insert]

      # Save the highlighted text
      lappend result [selection get]

  ---- Result was:
  {A Tcl/Tk selection test!} 6 18 {Tk selection} 4 {l/Tk
  selection}
  ---- Result should have been:
  {A Tcl/Tk selection test!} 6 18 {Tk selection} 2
  {Tcl/Tk selection}
  ==== event-click-drag-1.2 FAILED


tkt_uuid: 483836ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 55. [focus]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Works For Me
title: focus.test focus-5.1 ChangeXFocus fails
comment:
  sparc/sun solaris 2.6/sun c compiler/cde window manager

  focus.test

  ==== focus-5.1 ChangeXFocus procedure, don't take focus
  unless have it FAILED
  ==== Contents of test case:

      focusSetup
      focus -force .t
      update
      set result [focus]
      send [dobg {tk appname}] {focus -force .; update}
      lappend result [focus]
      focus .t.b2
      update
      lappend result [focus]

  ---- Result was:
  .t .t {}
  ---- Result should have been:
  .t {} {}
  ==== focus-5.1 FAILED


tkt_uuid: 483859ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Invalid
title: Text does not correctly right justify
comment:
  The text widget does not appear to correctly right 
  justify text. The following code produces text whose 
  first three display lines have a space displayed at 
  the end of them. These should not be there. The last 
  display line displays correctly.

  text .t -wrap word -font courier -width 20
  pack .t
  .t insert end "This is a sentence with enough words to 
  wrap once or twice." right
  .t tag configure right -justify right

  I've found this to be true on both HPUX and Windows 
  using Tk8.3.

  Dean Clamons


tkt_uuid: 484102ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: None
priority: 5 Medium
foundin: None
resolution: None
title: icon-position for -compound left option
comment:
  When using the new implemented "-compound left" option 
  from the menu-command, this icon is position to the 
  left of the "text-column".
  I suppose the icon should be put in the column where 
  the "selectimages" (refered to as "indicatorSpace") 
  are placed.

  This is in tkWinMenu.c (for Tk 8.4a4):

  To position the icon in the "indicator"-column (which 
  looks more windows-like :-)), simply 
  function "DrawMenuEntryLabel" has to be modified
  from 

  --------------------------------------------------
  switch ((enum compound) mePtr->compound) {
  ...
  case COMPOUND_LEFT: {
    textXOffset = imageWidth + 2;
    textYOffset = 0;
    imageXOffset = 0;
    imageYOffset = 0;
    break;
  }
  --------------------------------------------------

  to 
  --------------------------------------------------
  case COMPOUND_LEFT: {
    textXOffset = 0;
    textYOffset = 0;
    imageXOffset = x+activeBorderWidth-leftEdge;
    imageYOffset = 0;
  ´ break;
  }
  --------------------------------------------------

  Thanks in advance
    Stefan


tkt_uuid: 485803ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: suspect code in tkImage.c
comment:
  A compiler warning about unreachable code in
  generic/tkImage.c brought my attention to 
  lines 371-377:

  371 if (masterPtr->typePtr != NULL) {
  372   for (imagePtr = masterPtr->instancePtr; imagePtr
  != NULL;
  373     imagePtr = imagePtr->nextPtr) {
  374        count = 1;
  375        break;
  376   }
  377 }

  The unconditional break inside the for loop
  does look suspect.  Is it meant to be a
  break in the case statement?  Worth a look
  by the maintainer anyway.


tkt_uuid: 485986ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 74. Application Embedding
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: UTF8 in "Error in startup script"
comment:
  "Error in startup script" dialog
  can't display non-ASCII symbols on Windows.

  Test script (\u0410 - russian letter 'A'):
  ----------
  error \u0410
  ----------

  Result: window with following text:
  --------
  ??
    while executing 
  "error \u0410"
    (file "test.tcl" line 1)
  --------


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

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

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

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

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

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


tkt_uuid: 487442ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 76. Widget Tour
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Fixed
title: changing font size in tk widget demo
comment:
  I work on windows-Me with a 1024x768 screen.

  The basic "widget demonstration" has a big
  font and, in my opinion, may give to newcomers the
  feeling that tk is a bit "kludge".

  Changing the line 26 of widget.tcl 
  from "set font {Helvetica 14}"
  to "set font {Helvetica 10}"   (or 11)

  makes me feel much better, each time I install
  a new distribution. 

  I suggest to integrate this modification in the core
  distribution.


  V. Wartelle.


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

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


tkt_uuid: 487861ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.5.4
resolution: Accepted
title: cascade with -accelerator looks wrong
comment:
  If I create a cascade menu item and give it an 
  accelerator it looks wrong. The accelerator overwrites 
  the cascade items label from the left.

  Now I know it doesn't particularly make sense to have 
  an accelerator for a cascade, but the man page doesn't 
  say you can't, and suggests that if you do the 
  accelerator appears on the right.

  Here's how to reproduce:

  menu .m
  .m add cascade -label "Cascade" -accelerator "X"
  . configure -menu .m

  When I do the above on my box (win2k, tcl 8.2, 8.3 and 
  8.4) I see "Xascade"


tkt_uuid: 488416ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: None
resolution: Out of Date
title: MacOSX bundling for Aqua and X11
comment:
  Hi,

  The OSX port is great work, thanks for the native, X-indepent port. That is great for standalone apps. using only Tk.

  However, we also need a build for X11, to use with other opens source stuff linked with Tk and X11 (and other stuff, e.g. OpenGl in my case). I have hacked something together, which works : kinda merge AppInit.c's of Unix and MacOSX, and build for unix (undefing all Mac related stuff). I suggest packaging 2 different binary versions in the framework, e.g. 8.4 and 8.4X.

  I also have other suggestions for MacOSX bundling : rbarrow@users.sourceforge.net


tkt_uuid: 488429ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: None
resolution: Out of Date
title: on mac, toplevel pulses in this script
comment:
  When I source this file in wish 8.0.5 on macOS 8.0 or 8.5,
  it builds 4 listboxes horzontally aligned and a vertical scrollbar.
  If I don't add '-padx 1' (1 or more) to the grid command of the
  scrollbar or
  one of its parent frames, my toplevel pulses at the point where
  the scrollbar touches it. I was told by das that this is also in current
  8.3.4 and 8.4.a4.


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

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

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


tkt_uuid: 489328ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Fixed
title: cursor steps into elided text
comment:
  When using the "-elide" option in the Tk text widget
  (Tcl/Tk 8.3.4) we noticed that the cursor movements
  don't skip the "hidden" parts.

  Enter the following code in a wish console.

  ##### Start of example #####

  text .t
  pack .t
  .t insert end "1111111111\n"
  .t insert end "2222222222\n" hide_me
  .t insert end "3333333333\n"
  .t tag configure hide_me -elide 1
  .t mark set insert 1.5

  ##### End of example #####

  The cursor should now be at char 5 on the first line.

  Now press the "down" arrow key.
  The cursor disappears, it is in the "elided" (=hidden
  part).
  Press "down" ones more, and the cursor is back (on the
  line containing the 3's).

  Second test. Press "up" key.
  The cursor disappears.
  Now enter ".t tag configure hide_me -elide 0" in the
  wish console.
  The second line (containg 2's) should become visible
  and the insert cursor is on this line.

  These simple tests show that the elide-patch is incomplete.

  If you attach scrolbars to a text widget that contains
  elided text, you will also notice "strange" scrolbars
  changes.


tkt_uuid: 489756ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 2
foundin: obsolete: 8.3.4
resolution: Wont Fix
title: Embedded windows obscure the border
comment:
  Embedded windows when partially scrolled out of the
  current view of the canvas are drawn over the 3d border
  of the canvas instead of below.


tkt_uuid: 490051ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Fixed
title: wish segfaults deleting a label
comment:
  'wish' appears to get a segfault if a label widget is deleted from an 'unset' trace on its textvariable.

  Test script:

  toplevel .t
  wm title .t "Countdown"
  grid [label .t.val -textvariable v -width 24]
  trace variable v u [list destroy .t]
  proc doit {} {
      global v
      if { $v == 0 } {
  unset v
      } else {
  incr v -1
  after 1000 doit
      }
  }
  set v 10
  after 1000 doit

  Resulting stack trace:

  Program received signal SIGSEGV, Segmentation fault.
  Tcl_GetString (objPtr=0x0) at ../unix/../generic/tclObj.c:792
  792         if (objPtr->bytes != NULL) {
  #0  Tcl_GetString (objPtr=0x0) at ../unix/../generic/tclObj.c:792
  #1  0x80900 in ButtonTextVarProc (clientData=0x2c24e8, interp=0x23f1b8,
      name1=0x29a150 "v", name2=0x0, flags=192)
      at /local/src/tk/unix/../generic/tkButton.c:1628
  #2  0x1c7d04 in CallTraces (iPtr=0x23f1b8, arrayPtr=0x0, varPtr=0xffbede00,
      part1=0x29a150 "v", part2=0x0, flags=192, resultTypePtr=0xffbedddc)
      at ../unix/../generic/tclVar.c:4606
  #3  0x1c3868 in Tcl_UnsetVar2 (interp=0x23f1b8, part1=0x29a150 "v", part2=0x0,
      flags=512) at ../unix/../generic/tclVar.c:2364
  #4  0x1c43dc in Tcl_UnsetObjCmd (dummy=0x0, interp=0x23f1b8, objc=2,
      objv=0x23fe10) at ../unix/../generic/tclVar.c:2883
  #5  0x127a40 in TclEvalObjvInternal (interp=0x23f1b8, objc=2, objv=0x23fe10,
      command=0x0, length=0, flags=0) at ../unix/../generic/tclBasic.c:2935
  #6  0x15e934 in TclExecuteByteCode (interp=0x23f1b8, codePtr=0x2cbc70)
      at ../unix/../generic/tclExecute.c:1258
  #7  0x15dbc0 in TclCompEvalObj (interp=0x23f1b8, objPtr=0x2a7d50, engineCall=0)
      at ../unix/../generic/tclExecute.c:844
  #8  0x128eac in Tcl_EvalObjEx (interp=0x23f1b8, objPtr=0x2a7d50, flags=0)
      at ../unix/../generic/tclBasic.c:3748
  #9  0x1ae8f8 in TclObjInterpProc (clientData=0x2c5058, interp=0x23f1b8,
      objc=1, objv=0xffbee6f8) at ../unix/../generic/tclProc.c:1074
  #10 0x127a40 in TclEvalObjvInternal (interp=0x23f1b8, objc=1, objv=0xffbee6f8,
      command=0x2c3200 "doit", length=4, flags=0)
      at ../unix/../generic/tclBasic.c:2935
  #11 0x128738 in Tcl_EvalEx (interp=0x23f1b8, script=0x2c3200 "doit",
      numBytes=4, flags=131072) at ../unix/../generic/tclBasic.c:3459
  #12 0x1b8b98 in AfterProc (clientData=0x2cb4b0) 


tkt_uuid: 491427ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
severity: Minor
foundin: None
resolution: Fixed
title: Windows bindings - case sensitive
comment:
  Most of the keyboard bindings in Tk are lowercase 
  only, this means that when a user tries to activate a 
  keyboard binding with the capslock light on the 
  keypress is ignored.

  I've modified tk.tcl as follows at about line 315:

      "windows" {
   event add <<Cut>> <Control-Key-x> <Control-Key-X> 
  <Shift-Key-Delete>
   event add <<Copy>> <Control-Key-c> <Control-Key-C> 
  <Control-Key-Insert>
   event add <<Paste>> <Control-Key-v> <Control-Key-V> 
  <Shift-Key-Insert>
   event add <<PasteSelection>> <ButtonRelease-2>
      }

  As the keyboard bindings are case sensitive I've had 
  to add the capital X/C/V bindings also.

  I posted this on comp.lang.tcl, some notes were made 
  about distinguishing between control-key and control-
  shift-key but as discussed this shouldn't cause any 
  problems. When capslock is on the user isn't pressing 
  Shift.

  All other bindings should be reviewed also and 
  extended to include upper and lower case(?).


tkt_uuid: 492220ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 37. [tk_get*File]
priority: 1 Zero
foundin: None
resolution: Fixed
title: Improve handling of default extensions
comment:
  We found tk_getSaveFile wasn't handling default extensions the way users 
  expected on UNIX, especially as compared to the same dialog on 'Windows.

  It was always true that if the option -defaultextension ext was supplied, 
  "ext" was used if the user entered a file name without an extension.  However,
  when specifying file types, some non-intuitive behavior could result.  With this 
  patch, if no option -defaultextension ext is supplied, the first extension for the 
  first data type is used.   For example, user selects postscript type which has 
  the filters "*.ps *.eps".  We'll append ".ps" to the file name, if an extension has 
  not been supplied in the file name.


tkt_uuid: 492259ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 7 High
foundin: obsolete: 8.4a4
resolution: Fixed
title: wm-stackorder-5.1 fails
comment:
  Using the current HEAD Tcl and Tk on Solaris 8,
  CDE window manager:

  ==== wm-stackorder-5.1 overrideredirect does not change
  stackorder FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t
      wm overrideredirect .t 1
      update
      raise .
      wm stackorder . isabove .t

  ---- Result was:
  0
  ---- Result should have been:
  1
  ==== wm-stackorder-5.1 FAILED


tkt_uuid: 493145ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: Fixed
title: Scale binding on Windows
comment:
  The scale bindings work well with three button mice, 
  allowing the middle button to jump to specific 
  locations on the scale. However on windows, must users 
  have two button mice with the "second" button being 
  called button 3. The patch below to the scale widget 
  binds the normal button 2 bindings to button 3. Note, 
  this could also be done with virtual events so the 
  below code is more of an example. Also, on the Mac, 
  only one button is used which makes things even more 
  difficult.

  Tom Wilkason

  cvs -z3 diff -w scale.tcl (in directory 
  D:\CVS\sourceforge\tk\library\)
  Index: scale.tcl
  =======================================================
  ============
  RCS file: /cvsroot/tktoolkit/tk/library/scale.tcl,v
  retrieving revision 1.8
  diff -w -r1.8 scale.tcl
  51a52,68
  > switch -- $tcl_platform(platform) {
  >    "windows" {
  >       bind Scale <3> {
  >           tk::ScaleButton2Down %W %x %y
  >       }
  >       bind Scale <B3-Motion> {
  >           tk::ScaleDrag %W %x %y
  >       }
  >       bind Scale <B3-Leave> { }
  >       bind Scale <B3-Enter> { }
  >       bind Scale <ButtonRelease-3> {
  >           tk::CancelRepeat
  >           tk::ScaleEndDrag %W
  >           tk::ScaleActivate %W %x %y
  >       }
  >    }
  >    default {
  64a82,83
  >    }
  > }

  *****CVS exited normally with code 1*****


tkt_uuid: 493147ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 20. [tk_optionMenu]
priority: 2
foundin: None
resolution: None
title: Remove need for eval
comment:
  I use the tk_optionMenu quite often and have seldom 
  know the list of options to add at runtime. Therefore 
  I have needed to do a eval trick to pass in a dynamic 
  list of options. The use of eval should be avoided. 
  Therefore I patched the tk_optionMenu to support a -
  list option when if chosen, will expect a list of 
  arguments passed in to add as options in the menu. Eg.

  existing way (still supported)
  tk_optionMenu .widget ::Variable opt1 opt2 opt3 ...
  new support
  tk_optionMenu .widget ::Variable -list {opt1 opt2 
  opt3 ...}

  This allows the list to be dynamically created.



  cvs -z3 diff -w optMenu.tcl (in directory 
  D:\CVS\sourceforge\tk\library\)
  Index: optMenu.tcl
  =======================================================
  ============
  RCS file: /cvsroot/tktoolkit/tk/library/optMenu.tcl,v
  retrieving revision 1.4
  diff -w -r1.4 optMenu.tcl
  39a40,47
  >     ;# -list option tells us to treat argument as 
  nested list
  >     if {[string equal $firstValue "-list"]} {
  >        foreach subList $args {
  >           foreach {i} $subList {
  >             $w.menu add radiobutton -label $i -
  variable $varName
  >           } ;# end foreach
  >        }
  >     } else {
  42a51
  >        }

  *****CVS exited normally with code 1*****


tkt_uuid: 493402ffffffffffffffffffffffffffffffffff
type: Patch
status: Deleted
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: TIP Implementation
resolution: Accepted
title: TIP 48: style patch
comment:
  Modified version of:

  http://www.multimania.com/fbonnet/pub/style.patch

  This patch is not yet ready to be applied.


tkt_uuid: 4939f815b9ae1c4b76fd102d0ab48fb194ab45c9
type: Bug
status: Open
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
severity: Cosmetic
foundin: 8.6.0
private_contact: e407c8682857ccbf1757ae6bd67e3a0e7f43af71
resolution: None
title: Problem (bug?) with tk_chooseDirectory in 8.5.13 and 8.6.0
comment:
  In tk 8.5.7, when given an initial directory name, tk_chooseDirectory will locate the directory on the GUI. And when selecting the directory, the directory full path will be shown on the top of the dialog box.  For 8.5.13 and 8.6.0, all these are gone.

  I was able to copy the source code of 8.5.7 into 8.5.13 and restore the behavior. But not anymore  in 8.6.0.

  Is there any way I can get these nice feature back ?


tkt_uuid: 494789ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.4a3
resolution: Fixed
title: spinup, spindown s.b. buttonup, ...down
comment:
  spinbox.n talks about spinup and spindown in the identify and invoke subcommands.  The source 
  uses buttonup and buttondown.


tkt_uuid: 495100ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: None
resolution: None
title: Add invoke none subcommand
comment:
  It is sometimes desirable to invoke the code associated with a spinbox's 
  -command option directly such as in a validation routine.  % substitutions
  prevent this from being done with something like:

     eval [$sb cget -command]

  This patch adds "none" as a value identifier to the spinbox's invoke subcommand.
  Code like:

     $sb invoke none

  will perform % substitutions and invoke the command but will not change the value
  of the spinbox.  I've used this in code like:

     proc spinboxCmd { w } {
         # Do something here to make the application react to the value.
         puts " new value:[$w get]"
     }

     proc spinboxVal { w v } {
         if { ! [string is integer $v]} {
     return 0
         } elseif {[string length $v]} {
     set values [$w cget -values]

     if {[llength $values]} {
         if {[lsearch $values $v] == -1} {
     return 0
         }
     } else {
         if {$v < [$w cget -from]
         || $v > [$w cget -to]} {
     return 0
         }
         # WUZ - worry about increment?
     }
         }

         # OK, the new value is OK, invoke the command
         after idle $w invoke none

         # It's valid.
         return 1
     }

     spinbox .sb -width 5 \
     -from 0 -to 10 -increment 1 \
     -command [list spinboxCmd %W] \
     -vcmd [list spinboxVal %W %P] \
     -validate key


tkt_uuid: 495549ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 74. Application Embedding
priority: 5 Medium
foundin: None
resolution: Accepted
title: Allow easier embedding on Mac OSX
comment:
  This patch, developed by Robert Kedoin and I, moves
  some MacOSX-specific calls out of the Tcl_AppInit
  function and into the TkpInit function.  This frees
  applications that embed Tcl/Tk from making those same
  MacOSX specific calls in thier own Tcl_AppInit.

  (The good stuff is due to Robert, blame me for bad stuff)


tkt_uuid: 496669ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.3.3
resolution: None
title: last selected char without selectbg
comment:
  I use Windows 2000.

  When I select a pièce of text in an entry widget the 
  background color of the last char of the selection is 
  wrong.

  All selected char have the good foreground color 
  (selectforegound).
  All selected char but the last have the good 
  background color (selectbackground).
  The last selected char keeps its previous background 
  color.

  ulis


tkt_uuid: 498684ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Fixes jumpy multi-widget scrolling
comment:
  A Listbox, Textbox, and Entry packed in the same frame 
  and bound to the same horizontal scrollbar will scroll 
  differently (even when they include the same text) due 
  to a rounding error.

  See bug 225025 for details (and a demonstration 
  script).


tkt_uuid: 499168ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 17. [spinbox]
priority: 6
foundin: obsolete: 8.4a4
resolution: Fixed
title: Extra step when double clicking spinbox.
comment:
  When clicking twice on a spinbox's up or down arrow, the
  value might change three steps if you click fast enough.

  It seems that the doubleclick binding in ::tk::spinbox::MouseSelect
  invokes the arrow which gives the extra value change. 
  My guess is that it should do the same as the ButtonPress binding
  in ::tk::spinbox::ButtonDown does and leave the invoking to the
  ButtonRelease event.


tkt_uuid: 4a48c498aaf0029a83391ab30bcf495673a9d4e9
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
severity: Minor
foundin: 8.5.10
private_contact: 2e16cf44a6a74fa6537df233cfdd5b7694defa05
resolution: Duplicate
title: ttk::entry widgets cannot "xview end"
comment:
  Passing the "end" index to the xview subcommand returns an error: expected integer but got "end"

  $ tclsh
  % package req Tk
  8.5.10
  % ttk::entry .e
  .e
  % pack .e
  % .e conf -textvar foo
  % set foo {qpowieurpoqwyerpiqyweritqywpeityqwpeitrqiweyrioqwter1234}
  qpowieurpoqwyerpiqyweritqywpeityqwpeitrqiweyrioqwter1234
  % .e xview end
  expected integer but got "end"
  % .e xview [string length [.e get]]   ;# works
  % .e xview [.e index end]             ;# works

  Also reported in version 8.5.11


tkt_uuid: 500846ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: tktest crashes immediately
comment:
  Platform: SPARC Solaris 2.6 Sun compiler and CDE window
  manager.

  Compiled with debugging.

  When i do a make test, I get this error:
  export LD_LIBRARY_PATH; \
  LIBPATH=`pwd`:/vol/tclsrcsol/tcl84/tcl/unix:; export
  LIBPATH; \
  SHLIB_PATH=`pwd`:/vol/tclsrcsol/tcl84/tcl/unix:; \
  export SHLIB_PATH; \
  TCL_LIBRARY=/vol/tclsrcsol/tcl84/tcl/library; export
  TCL_LIBRARY; \
  TK_LIBRARY=/vol/tclsrcsol/tcl84/tk/library; export
  TK_LIBRARY; \
  ./tktest /vol/tclsrcsol/tcl84/tk/unix/../tests/all.tcl
  -geometry +0+0 \
   
  Segmentation Fault - core dumped
  make: *** [test] Error 1139

  dbx tktest core
  (dbx 7) where
    [1] Tcl_GetString(objPtr = (nil)), line 792 in
  "tclObj.c"
  =>[2] TclGetStartupScriptFileName(), line 178 in
  "tclMain.c"
    [3] Tk_MainEx(argc = 4, argv = 0xefffe39c,
  appInitProc = 0x28cf8 = &Tcl_AppInit(Tcl_Interp
  *interp), interp = 0x48110), line 145 in "tkMain.c"
    [4] main(argc = 4, argv = 0xefffe39c), line 77 in
  "tkAppInit.c"

  TclGetStartupScriptFileName should not call
  Tcl_GetString without checking that the return is
  non-null - or Tcl_GetString should check that the
  pointer given to it is non-null rather than just using
  it.

  Then, of course, there is the whole matter of why
  tclgetstartupscriptpath is returning null...


tkt_uuid: 502026ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 06. Canvas Postscript
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: None
title: Font scale incorrect in postscript
comment:
  In the tk8.3.4 (and all earlier distributions) the 
  Tk_PostscriptFontName routine returns the size of the 
  font. It may (in principle) be either in points or 
  pixels. In practice it has been converted to points by 
  this time.

  The postscript file contains a postscript scale 
  command at the start of the file that defines all the 
  canvas pixel coordinates be converted to points so 
  that points are the "postcript unit". The scalefont 
  command goes further and scales the font to be scaled 
  by the number of points.

  If you:
  1. place on the canvas a font of size 40 with the 
  text "This is some text"
  2. get the bounding box of the text and draw a box 
  around the text using this.
  3. generate a postscript file of the canvas with a -
  pageheight of 8i
  4. Look at the results in Ghostscript or on a printer

  Notice that the bounding box is larger than the text.

  I believe that the points must be scaled to pixels 
  before calling "scalefont" so that they are converted 
  back to points as a result of the "scale" command. 
  This should be done after the call to 
  Tk_PostscriptFontName in Tk_PostscriptFont in 
  tkCanvPs.c.


tkt_uuid: 503772ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Fixed
title: Nonblinking cursor in TW after disabling
comment:
  Hi,

  the summary should be read as: "Cursor does not blink 
  in text widget after disabling and enabling". 40 
  symbol limit in summary seems to be too restrictive.


  When changing state of the text widget to disabled and 
  then back to normal the cursor doesn't blink in it. It 
  is either steady or absent. If you switch focus 
  manually to another text widget, or move it out of the 
  window and then return back blinking works again 
  correctly (for all tested platforms).

  This misbehavior was 100% of times reproducible at 
  least on two different kinds of platforms:

  1) Windows2000/XP + ActiveState tcl/tk 8.3.4.1-8/9
  2) freeBSD 4.4 + tcl/tk 8.3.4

  However, spark sunos 5.8 + tcl/tk 8.3b1 works fine 
  without aforementioned problem.

  In my script two stupid methods of avoiding of the 
  problem are suggested. However, both reset-procedures 
  work only for the platform 1). Only reset2 works for 
  platform 2).

  Desirable behavior:
  Cursor in the text widget after disabling/enabling 
  should blink without extra code and system-dependency.

  Alexander Buzin

  #beginning of example

  set widget_status normal

  text .t1 -width 50 -height 10
  text .t2 -width 50 -height 10
  radiobutton .r1 -text "Normal" \
  -variable widget_status -value normal \
  -command { .t1 configure -state normal }
  radiobutton .r2 -text "Disabled" \
  -variable widget_status -value disabled \
  -command { .t1 configure -state disabled }

  button .b1 -text "Reset Text Widget1" \
  -command {reset1 .t1}
  button .b2 -text "Reset Text Widget2" \
  -command {reset2}

  grid .r1 .r2 -sticky ew
  grid .t1 .t2 -columnspan 2
  grid .b1 .b2 -row 2

  wm deiconify .
  focus .t1

  #suggested by Steve Offutt
  proc reset1 { widget } {
  global widget_status
  set widget_status normal
  $widget configure -state normal
  event generate . <FocusOut>
  event generate . <FocusIn>
  focus $widget
  }

  proc reset2 { } {
  focus .t2
  focus .t1
  }

  #end of example


tkt_uuid: 503852ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Invalid
title: Cannot compile Tk unix build on MAC OSX
comment:
  I attempted to compile the Unix build of TK on MAC OS X. 
  MAC OSX has a Unix implementation known as Darwin. 
  Apparently the Unix build for TCL successfully compiled. 
  When I attempted to compile Tk, I got a list of 
  undefined symbols and the message that the internal link 
  edit command failed.

  The actual errors are included in an attached text file.

  I am aware of the MAC classic builds for TCL/TK, but I 
  run the unix version of python which needs the unix 
  builds for TCL/TK in /usr/local/bin. 

  Thank you for your time.


tkt_uuid: 504229ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: compiler warnings
comment:
  gcc -pipe -c -O -D__NO_STRING_INLINES
  -D__NO_MATH_INLINES -Wall -Wconversion
  -Wno-implicit-int -fPIC -I/home/dgporter/cvs/tk/unix
  -I/home/dgporter/cvs/tk/unix/../generic
  -I/home/dgporter/cvs/tk/unix/../bitmaps
  -I/home/dgporter/cvs/tcl/generic -I/usr/X11R6/include
  -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DSTDC_HEADERS=1
  -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1
  -DHAVE_PW_GECOS=1 -DSTATIC_BUILD=1
  -DTCL_NO_DEPRECATED  
  /home/dgporter/cvs/tk/unix/tkUnixMenu.c
  /home/dgporter/cvs/tk/unix/tkUnixMenu.c: In function
  `DrawMenuEntryLabel':
  /home/dgporter/cvs/tk/unix/tkUnixMenu.c:710: warning:
  `textHeight' might be used uninitialized in this function
  /home/dgporter/cvs/tk/unix/tkUnixMenu.c:710: warning:
  `textWidth' might be used uninitialized in this function
  /home/dgporter/cvs/tk/unix/tkUnixMenu.c: In function
  `GetMenuLabelGeometry':
  /home/dgporter/cvs/tk/unix/tkUnixMenu.c:1476: warning:
  unused variable `haveText'


tkt_uuid: 504356ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: latest cvs problem with TCL_DBGX
comment:
  After downloading , configuring, and attempting to make
  the code for Tk, I ran into a peculiar problem.

  I kept getting this error:

  ld: fatal: library -ltclstub8.4: not found
  ld: fatal: File processing errors. No output written to
  libtk8.4g.so
  make: *** [libtk8.4g.so] Error 1

  Upon investigation, I found this much out.  Tcl was
  built with symbols .  This  installs libtclsub8.4 with
  the 'g' suffix (libtclstub8.4g.a) .

  Now, tclConfig.sh indicates 
  TCL_DBGX=g
  and 
   TCL_STUB_LIB_FILE='libtclstub8.4${TCL_DBGX}.a'

  TCL_STUB_LIB_FLAG='-ltclstub8.4${TCL_DBGX}'
  TCL_BUILD_STUB_LIB_SPEC='-L/vol/tclsrcsol/tcl84/tcl/unix
  -ltclstub8.4${TCL_DBGX}
  TCL_STUB_LIB_SPEC='-L/usr/tcl84/lib
  -ltclstub8.4${TCL_DBGX}'

  TCL_BUILD_STUB_LIB_PATH='/vol/tclsrcsol/tcl84/tcl/unix/libtclstub8.4${TCL_DBGX}.
  a'
  TCL_STUB_LIB_PATH='/usr/tcl84/lib/libtclstub8.4${TCL_DBGX}.a'

  so it LOOKS like everything should have worked okay.

  I haven't figured out why this fails.  However, if I
  hand edit the Tk Makefile to foce the TCL_DBGX to g,
  the makefile works.

  Note that I see the same problem with the itcl
  makefile...


tkt_uuid: 504705ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 5 Medium
foundin: TIP Implementation
resolution: Accepted
title: TIP 27: Tcl_GetIndexFromObj* callers
comment:
  Changes needed to callers of the Tcl routines
  Tcl_GetIndexFromObj(Struct) due to TIP 27 changes
  in that interface.  [Tcl Patch 504671]


tkt_uuid: 505159ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 5 Medium
foundin: TIP Implementation
resolution: Accepted
title: TIP 27: tcl{FileName,Result,Var}.c callers
comment:
  Attached patch updates callers of Tcl interfaces
  changed by Tcl Patch 505072.  When that is committed,
  commit this too.


tkt_uuid: 505616ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: listbox-13.3 fails
comment:
  After the 2002-01-16 commit to tkListBox.c, test
  listbox-13.3 began failing on both Solaris/CDE
  and Linux/Alpha/GNOME.

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

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

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


tkt_uuid: 508677ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Invalid
title: threaded wish, Solaris 8, Workshop 6 bad
comment:
  First built and tested Tcl with --disable-shared,
  --enable-threads.

  Then in Tk, using the Sun Workshop 6 C compiler:

  $ mkdir solaris
  $ cd solaris
  $ setenv CC cc
  $ ../unix/configure --disable-shared --enable-threads
  --with-tcl=../../tcl/unix
  ...
  $ make
  ...
  cc  tkAppInit.o \
          -L/local/src/tk/solaris -ltk8.4 \
          -L/local/src/tcl/unix -ltcl8.4  -lsocket -lnsl
  -lpthread -L/usr/openwin/lib -lX11 -ldl -lm
  -Wl,-rpath,/usr/local/lib:/usr/openwin/lib -o wish
  ld: fatal: file /usr/local/lib:/usr/openwin/lib: open
  failed: No such file or directory

  Something wrong with TK_CC_SEARCH_FLAGS ?  Not
  matching what the compiler expects?


tkt_uuid: 508988ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Fixed
title: Replacing menus fails (example & fix)
comment:
  The Tcl code below fails. The problem has also
  been present in 8.3.2 and has been reported,
  but has not been fixed up to now. The fix
  works for 8.3.2/8.3.3/8.3.4 and is VERY OBVIOUS.

  test misc-1.7 {Tk Menu problem, fixed by PRS in
  tkMenu.c} {
      set t .t
      set m1 .t.m1
      set c1 .t.c1
      set c2 .t.c2
      
      toplevel $t
      menu $m1 -tearoff 1
      menu $c1 -tearoff 1
      $c1 add command -label c1
      menu $c2 -tearoff 1
      $c2 add command -label c2
      $m1 add cascade -label c1 -menu $c1
      $t configure -menu $m1
      $m1 entryconfigure 1 -menu $c2 -label c2
      $t configure -menu ""
      set l [list [winfo exists $c1] [winfo exists $c2]]
      destroy $t;
      set l;
  } {1 1}

  Fix:
  Change generic/tkMenu.c:1986 (old):

      cascadeEntryChanged = (strcmp(oldCascadeName,
  newCascadeName) 
      == 0);


  into:
      /* start wke changes */
      /* Fix for menu problem */
      /* 
      cascadeEntryChanged = (strcmp(oldCascadeName,
  newCascadeName) 
      == 0);
      */
      cascadeEntryChanged = strcmp(oldCascadeName,
  newCascadeName);
      /* end wke changes */


tkt_uuid: 509387ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: Clipboard doesn't work.
comment:
  The command "selection get -selection 
  CLIPBOARD" doesn't work if receiving the 
  clipboard from another application. It works 
  internally, but not from another application. The 
  older 8.0b2 version work... However, newer version 
  has never work since then.

  I was hoping the newer version is using the Mac 
  OS X Project Builder, so I could possibly fix it, but 
  appears still using Code Warrior which I do not 
  have the latest version (i.e., 3).


tkt_uuid: 509974ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 63. Tk_Win Functions
priority: 2
foundin: obsolete: 8.4a4
resolution: None
title: pkg_mkIndex libtk.so requires DISPLAY
comment:
  To be able to create a package index for Tk as
  a loadable package using [pkg_mkIndex], one
  must be able to load Tk.  That, in turn,
  requires an X DISPLAY on Unix.

  This means one cannot create an index during
  an install of Tk as a loadable package in the
  conventional way on a headless box -- common
  installation practice on Unix.


tkt_uuid: 511431ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: None
title: Error processing events (bug&workaround)
comment:
  Please watch the code below, run it
  an call nogo. Behavior:
  Tcl-Error for generated event. The idea behind the
  code is to generate an event when an item in the
  canvas is picked ny the user.
  The function doeswork does the same with a frame
  and widgets, here processing generated events
  works fine.
  The code has been distilled from a much more
  complex example.

  proc f {} {
      catch {event generate $::evw <Button-1> -x 15 -y 15
  -when mark}
  }
  proc cb1 {} {puts cb1}
  proc cb2 {} {puts cb2; f}

  proc nogo {} {
      toplevel .t
      set ::evw [canvas .t.c];
      pack .t.c -fill both -expand 1
      set ::r1 [.t.c create rect 10 10 20 20 -fill red]
      set ::r2 [.t.c create rect 100 10 110 20 -fill
  green]
      $::evw bind $::r1 <ButtonPress-1> "cb1";
      $::evw bind $::r2 <ButtonPress-1> "cb2";
  }

  proc doeswork {} {
      toplevel .t
      set ::r1 [frame .t.f1 -bg green -width 10 -height
  10];
      place .t.f1 -x 10 -y 10
      set ::r2 [frame .t.f2 -bg red -width 10 -height
  10];
      place .t.f2 -x 100 -y 10
      set ::evw $::r1;
      bind $::r1 <ButtonPress-1> cb1;
      bind $::r2 <ButtonPress-1> cb2;
  }


  Possible WORKAROUND:
  in generic/tkEvent.cTk_HandleEvent, lines 559..578:
  deactive these lines with #if 0/#endif will make
  this example and many other cases work, but it
  breaks some of the tests coming with Tk.
  I have currently no idea about the consequences
  of this workaround, but I used it for 8.3.2/8.3.3
  as well. I assume the correct fix needs to touch
  the canvas widget C-code dealing with event handling.


tkt_uuid: 511956ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 81. Portability
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: "bool" is #defined to _Bool in ISO 99 C
comment:
  The ISO 99 C standard now requires that C 
  compilers define bool to be _Bool.  If you want to 
  use bool in your code, you have to undef it first.  
  This only shows up in one place in Tk, so rather 
  than fighting with the compiler, we should just 
  change it.  Here is the patch (just changing the int 
  bool variable to int boolval):

  Index: tkCmds.c
  =======================================
  ============================
  RCS file: /cvsroot/tktoolkit/tk/generic/tkCmds.c,v
  retrieving revision 1.20.2.2
  diff -c -w -r1.20.2.2 tkCmds.c
  *** tkCmds.c    2001/10/17 07:02:07     1.20.2.2
  --- tkCmds.c    2002/02/01 23:14:46
  ***************
  *** 709,721 ****
                   * That will indicate to the user that input 
  methods
                   * are just not available.
                   */
  !               int bool;
  !               if (Tcl_GetBooleanFromObj(interp, objv[2+
  skip], &bool)
                          != TCL_OK) {
                      return TCL_ERROR;
                  }
    #ifdef TK_USE_INPUT_METHODS
  !               dispPtr->useInputMethods = bool;
    #endif /* TK_USE_INPUT_METHODS */
              } else if ((objc - skip) != 2) {
                  Tcl_WrongNumArgs(interp, 2, objv,
  --- 709,721 ----
                   * That will indicate to the user that input 
  methods
                   * are just not available.
                   */
  !               int boolval;
  !               if (Tcl_GetBooleanFromObj(interp, objv[2+
  skip], &boolval)
                          != TCL_OK) {
                      return TCL_ERROR;
                  }
    #ifdef TK_USE_INPUT_METHODS
  !               dispPtr->useInputMethods = boolval;
    #endif /* TK_USE_INPUT_METHODS */
              } else if ((objc - skip) != 2) {
                  Tcl_WrongNumArgs(interp, 2, objv,


tkt_uuid: 513210ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: menubutton font size is wrong
comment:
  MacOS X seems to have its own idea of what font a menu
  button should use, which is perhaps a worthy design
  principle. However Tk assumes that the OS is listening
  to it and so sets the size of the button itself.

  Eg:

  menubutton .m1 -text Menu -font {Courier 20}
  menubutton .m2 -text Menu -font {Courier 10}
  pack .m1
  pack .m2


tkt_uuid: 513213ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: Scrollbar appearance
comment:
  Perhaps this is a MacOS X bug, but a scrollbar that  
  covers a region from 0.0 to 1.0 draws incorrectly.

  Eg:

  scrollbar .y -command {.t yview}
  text .t -yscrollcommand {.y set} 
  pack .t .y -side left -fill both -expand 1

  The scrollbar only looks correct when enough 
  lines have been added to the text widget.
  Native MacOS X apps don't have this problem, but 
  perhaps they cheat some other way (eg by hiding 
  the scrollbar in this case).


tkt_uuid: 513216ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: Tearoff menu failure
comment:
  Tearoff menus do not work. Perhaps this feature 
  should simply be disabled in MacOS X?

  The tearoff menu does produce a new window, but 
  this window has the top clipped off, it is not 
  movable, and it can sometimes cause problems 
  with focusing to other windows.


tkt_uuid: 513219ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: wm buttons drawn wrongly
comment:
  The x, - and + buttons at the top left of every 
  window do not automatically highlight themselves 
  to reveal the x, - and + text whenever the mouse 
  moves over them (unlike other MacOS X windows).


tkt_uuid: 513222ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: Destroying a menu can crash Tk
comment:
  To implement context sensitive popup menus I 
  often create and destroy menu items on the fly. 
  However this can cause crashes in MacOS X Tk. (I 
  speculate that this sounds like a missing 
  Tcl_Preserve or Tcl_IncrRefCount call.)

  For example:

  bind . <1> {popup_menu "" %X %Y}

  proc popup_menu {w X Y} {
      if {[winfo exists $w.m]} {destroy $w.m}
      menu $w.m
      $w.m add command -label "testme" -command 
  newwin
      tk_popup $w.m $X $Y
  }

  proc newwin {} {
      destroy .m
  }


  A workaround is to use:

  proc newwin{} {
      after idle {destroy .m}
  }


tkt_uuid: 513688ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 1 Zero
foundin: obsolete: 8.4a4
resolution: Wont Fix
title: Updating button config -bg.
comment:
  After a button has been packed and made visible
  changing the background
  colour of the parent does not change the "invisible"
  component of the button background.

  For example:

  button .b  -text "test"
  pack .b
  update
  .b configure -bg green


tkt_uuid: 513690ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: button -padx options
comment:
  Specifying  low -padx options on buttons for aqua-tk
  causes the font to be clipped.

  This limitation is largely brought about due to the
  aqua look and feel. A possible solution is to have a
  minimum value (and ignore anything lower), although
  this minimum may be font dependent.


tkt_uuid: 513923ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: None
title: Tearoff+Cascade invokes wrong command
comment:
  When an item in a cascade from a tearoff is invoked,
  and the cascade overlaps the tearoff, both the command
  in the cascade and in its parent can be invoked.

  Expected behavior: Only the command in the cascade
  should be invoked.  *Probably, the cascade should be
  placed so that it does not overlap the tearoff at all*

  How to reproduce:  Execute the attached script by
  running "source menutest.tcl" from wish.  Tear off the
  "Test" menu.  Drag the tearoff to the extreme right
  side of the screen.  Post the cascade, then invoke a
  command from it (it may help if the mouse pointer is
  near the left hand side of the cascade).  Output reads
  something like
      % source x:/menutest.tcl
      Invoked 0
      Invoked Sub0
      %
  but it should only say
      Invoked Sub0

  This problem existed as early as 8.2.1, and still
  exists in 8.4a2.  None of the CVS changes since 8.4a2
  looked relevant to this problem, and no newer Windows
  installers were available.


tkt_uuid: 513948ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 5 Medium
foundin: TIP Implementation
resolution: Accepted
title: TIP 27: restore Tcl_DString use
comment:
  Once Tcl_DStrings are converted back to
  white-boxes (Tcl Patch 513947), this
  companion patch makes a few simplifications
  to Tk code.


tkt_uuid: 514374ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: tk_getOpenFile -initialdir fails
comment:
  As the subject says, tk_getOpenFile -initialdir [pwd] 
  (for example) fails with a "bad directory" message.

  One possible problem with this is due to using / 
  as a directory separator in old-style mac calls.

  tkMacOSXUtil.c specifies DIR_SEP_CHAR as 
  colon, but the pathname passed in to 
  FSpLocationFromPath contains slashes (it's 
  whatever [pwd] returned). I assume that the macos 
  calls require : instead. (I did try replacing the /s 
  with :s, but it didn't cure it.)

   


tkt_uuid: 515857ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 06. Canvas PostScript
priority: 6
foundin: None
resolution: None
title: Text. Underline/overstrike & non-latin font
comment:
  If a text item is requested to be underlined or 
  overstruck, then this is not reflected in the 
  generated postscript.

  Additionally, if a font such as ZapfDingbats is used, 
  that does not have a Latin encoding, this is not shown 
  when the postscript is displayed.

  I have made some changes to the text handling that 
  appears to resolve these problems, and I 
  enclose 'diff' output for the files I have changed 
  from the 8.4a3 distribution.

  diff tkCanvPs.c tkCanvPs.c.orig
  210,215d209
  <   % First test the encoding for this font.\n\
  <   % If this is a Latin font at position 65 will be 
  the encoding for\n\
  <   %  the letter \"A\".\n\
  <   % If it isn't a latin font, don't re-encode it.\n\
  <   dup /Encoding get 65 get (A) eq {\n\
  <     % Yes, this is a Latin font, re-encode it...\n\
  227d220
  <   }if\n\
  359,360d351
  <     /overstrike exch def\n\
  <     /underline exch def\n\
  407,410c398
  <         % Get the width of the characters to be 
  displayed in case we need\n\
  <         %  to underline or overstrike them.\n\
  < dup stringwidth pop dup /strwid exch def\n\
  < \n\
  ---
  > dup stringwidth pop\n\
  433,478d420
  < \n\
  <         overstrike {\n\
  <            newpath\n\
  <            currentfont /FontInfo get /fontinfo exch 
  def     % get current font info\n\
  <            currentfont /FontMatrix get /fontmatrix 
  exch def %  and the font transformation matrix\n\
  < \n\
  <            fontinfo /UnderlineThickness 
  get                 % get the underline thickness\n\
  <            0 
  exch                                           % put 
  in a dummy x value for dtransform\n\
  <            fontmatrix 
  dtransform                            % scale 
  according to font size\n\
  <            2 
  mul                                            % make 
  a bit thicker...\n\
  <            /overstrikethickness exch 
  def                    %  and save\n\
  <            
  pop                                              % pop 
  the dummy x
  < \n\
  <            0 0 
  moveto                                       % step 
  back to the start of the chars we drew\n\
  <            0 baseline height 2 div sub 
  rmoveto              % move to half-way up the 
  characters\n\
  <            
  currentlinewidth                                 % 
  save the current line width\n\
  <            overstrikethickness 
  setlinewidth                 % set the desired 
  underline thickness\n\
  <            strwid 0 
  rlineto                                 % underline 
  the characters\n\
  <            stroke\n\
  <            
  setlinewidth                                     % 
  restore the original line width\n\
  <         } if\n\
  < \n\
  <         underline {\n\
  <            newpath\n\
  <            currentfont /FontInfo get /fontinfo exch 
  def     % get current font info\n\
  <            currentfont /FontMatrix get /fontmatrix 
  exch def %  and the font transformation matrix\n\
  < \n\
  <            fontinfo /UnderlinePosition 
  get                  % get the underline position\n\
  <            0 
  exch                                           % put 
  in a dummy x value for dtransform\n\
  <            fontmatrix dtransform /underlinepos exch 
  def     % scale according to font size\n\
  <            
  pop                                              % pop 
  the dummy x
  < \n\
  <            fontinfo /UnderlineThickness 
  get                 % and get the underline 
  thickness\n\
  <            0 exch\n\
  <            fontmatrix dtransform /underlinethickness 
  exch def\n\
  <            pop\n\
  < \n\
  <            0 0 
  moveto                                       % step 
  back to the start of the chars we drew\n\
  <            0 0 underlinepos add 
  rmoveto                     % move down a bit\n\
  <            
  currentlinewidth                                 % 
  save the current line width\n\
  <            underlinethickness 
  setlinewidth                  % set the desired 
  underline thickness\n\
  <            strwid 0 
  rlineto                                 % underline 
  the characters\n\
  <            stroke\n\
  <            
  setlinewidth                                     % 
  restore the original line width\n\
  <         } if\n\
  < \n\




  diff tkCanvText.c tkCanvText.c.orig
  20d19
  < #include "tkFont.h"
  1507c1506
  <     sprintf(buffer, "] %d %g %g %s %s %s %s 
  DrawText\n",
  ---
  >     sprintf(buffer, "] %d %g %g %s %s DrawText\n",
  1509,1511c1508
  <     ((stipple == None) ? "false" : "true"),
  <     ((((TkFont *) textPtr->tkfont)-
  >fa.underline) ? "true" : "false"),
  <     ((((TkFont *) textPtr->tkfont)-
  >fa.overstrike) ? "true" : "false") );
  ---
  >     ((stipple == None) ? "false" : "true"));


tkt_uuid: 516751ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 25. Built-in Bitmaps
priority: 5 Medium
foundin: None
resolution: None
title: ASCII to XBM conversion script
comment:
  Attached is the Tcl source to convert ASCII art
  diagrams like:
  <pre>
  @@@@@
  .@@@.
  ..@..
  </pre>

  into XBM format suitable for passing into [image create
  bitmap -data ...].  This script is prompted by TIP 71
  and is submitted as an
  alternative to the suggestion of simply adding more
  hardcoded
  bitmaps into Tk.

  Eric Melski


tkt_uuid: 517600ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: tk_getOpenSaveFile and file types
comment:
  File types are not presented in the dialogue. For 
  example:

  tk_getSaveFile -filetypes {{gzip *.gz} {bzip *.bz}}


tkt_uuid: 517935ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: Setting scrollbar width fails
comment:
  Usng the native aqua-tk look.

  scrollbar .s -orient horiz
  button .b -text button
  pack .s .b -fill both -expand 1

  So the scrollbar has been given the same screen 
  area as the button.

  Now try resizing. The scrollbar refuses to change 
  width, which is perhaps a correct part of the Aqua-
  Tk interface.

  However it doesn't clear the screen space it 
  occupies either.

  Given that it's probably impossible to change the 
  scrollbar dimensions, I'd suggest that instead the 
  scrollbar is simply positioned as it is now, but the 
  additional screen space allocated to it is cleared.


tkt_uuid: 518057ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Invalid
title: tk-8.3.4 wont compile@ freebsd4.5-stable
comment:
  aleph# ./configure
  loading cache ./config.cache
  checking for ranlib... (cached) ranlib
  checking for gcc... (cached) cc
  checking whether the C compiler (cc  ) works... yes
  checking whether the C compiler (cc  ) is a cross-
  compiler... no
  checking whether we are using GNU C... (cached) yes
  checking whether cc accepts -g... (cached) yes
  checking how to run the C preprocessor... (cached) 
  cc -E
  checking for unistd.h... (cached) yes
  checking for limits.h... (cached) yes
  checking for building with threads... no (default)
  checking if the compiler understands -pipe... yes
  checking for Tcl configuration... (cached) 
  found /usr/local/src/tcl8.3.4/unix/tclConfig.sh
  checking for existence 
  of /usr/local/src/tcl8.3.4/unix/tclConfig.sh... 
  loading
  checking if 64bit support is requested... no
  checking if 64bit Sparc VIS support is requested... no
  checking system version (for dynamic loading)... 
  FreeBSD-4.5-STABLE
  checking for dlopen in -ldl... (cached) no
  checking for ar... (cached) ar
  checking for build with symbols... no
  checking for sin... (cached) no
  checking for main in -lieee... (cached) no
  checking stdlib.h... yes
  checking fd_set and sys/select... yes
  checking for ANSI C header files... (cached) yes
  checking for mode_t... (cached) yes
  checking for pid_t... (cached) yes
  checking for size_t... (cached) yes
  checking for uid_t in sys/types.h... (cached) yes
  checking for sys/time.h... (cached) yes
  checking whether time.h and sys/time.h may both be 
  included... (cached) yes
  checking pw_gecos in struct pwd... yes
  checking for X... (cached) no
  checking for X11 header files... couldn't find any!
  checking for X11 libraries... checking for 
  XCreateWindow in -lXwindow... (cached) no
  couldn't find any!  Using -lX11.
  checking for main in -lXbsd... (cached) no
  checking for connect... (cached) yes
  checking for gethostbyname... (cached) yes
  checking for sin... (cached) no
  checking for main in -lieee... (cached) no
  checking whether char is unsigned... (cached) no
  checking for strtod... (cached) yes
  checking for Solaris2.4/Tru64 strtod bugs... ok
  checking how to build libraries... shared
  updating cache ./config.cache
  creating ./config.status
  creating Makefile
  creating tkConfig.sh
  aleph# make
  cc -pipe -c -O -Wall -Wconversion -Wno-implicit-int -
  fPIC  -I/usr/local/src/tk8.3.4/unix -
  I/usr/local/src/tk8.3.4/unix/../generic  -
  I/usr/local/src/tk8.3.4/unix/../bitmaps -
  I/usr/local/src/tcl8.3.4/generic   -DHAVE_UNISTD_H=1 -
  DHAVE_LIMITS_H=1 -DSTDC_HEADERS=1 -
  DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -
  DHAVE_PW_GECOS=1      -
  DTCL_NO_DEPRECATED  /usr/local/src/tk8.3.4/unix/../gen
  eric/tk3d.c
  In file included 
  from /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:21
  ,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:18,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:16:
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:83: 
  X11/Xlib.h: No such file or directory
  In file included 
  from /usr/local/src/tk8.3.4/unix/../generic/tkPort.h:3
  2,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:27
  ,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:18,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:16:
  /usr/local/src/tk8.3.4/unix/../generic/../unix/tkUnixP
  ort.h:77: X11/Xlib.h: No such file or directory
  /usr/local/src/tk8.3.4/unix/../generic/../unix/tkUnixP
  ort.h:78: X11/cursorfont.h: No such file or directory
  /usr/local/src/tk8.3.4/unix/../generic/../unix/tkUnixP
  ort.h:79: X11/keysym.h: No such file or directory
  /usr/local/src/tk8.3.4/unix/../generic/../unix/tkUnixP
  ort.h:80: X11/Xatom.h: No such file or directory
  /usr/local/src/tk8.3.4/unix/../generic/../unix/tkUnixP
  ort.h:81: X11/Xproto.h: No such file or directory
  /usr/local/src/tk8.3.4/unix/../generic/../unix/tkUnixP
  ort.h:82: X11/Xresource.h: No such file or directory
  /usr/local/src/tk8.3.4/unix/../generic/../unix/tkUnixP
  ort.h:83: X11/Xutil.h: No such file or directory
  In file included 
  from /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:21
  ,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:18,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:16:
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:581: 
  syntax error before `Bool'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:591: 
  syntax error before `Bool'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:597: 
  syntax error before `Bool'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:657: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:660: 
  syntax error before `Visual'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:662: 
  syntax error before `Window'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:671: 
  syntax error before `XWindowChanges'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:673: 
  syntax error before `XSetWindowAttributes'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:787: 
  syntax error before `XPoint'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:887: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:889: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:985: 
  syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:1049: 
  syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:1061: 
  syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:1091: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:1094: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:1337: 
  syntax error before `XErrorEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:1339: 
  syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:1341: 
  syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:1343: 
  syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tk.h:1348: 
  syntax error before `XEvent'
  In file included 
  from /usr/local/src/tk8.3.4/unix/../generic/tk.h:1361,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:21
  ,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:18,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:16:
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:37: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:37: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:39: 
  syntax error before `Tk_3DBorderGC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:40: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:43: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:48: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:57: 
  syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:76: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:80: 
  syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:90: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:95: 
  syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:115: 
  syntax error before `XSetWindowAttributes'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:122: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:125: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:146: 
  syntax error before `XWindowChanges'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:164: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:185: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:229: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:239: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:244: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:248: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:254: 
  syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:256: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:262: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:267: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:274: 
  syntax error before `Tk_FontId'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:274: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:278: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:281: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:283: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:286: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:291: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:296: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:299: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:305: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:307: 
  syntax error before `Tk_GCForColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:307: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:308: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:324: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:330: 
  syntax error before `Tk_GetBitmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:331: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:333: 
  syntax error before `Tk_GetBitmapFromData'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:335: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:340: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:341: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:343: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:344: 
  syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:344: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:346: 
  syntax error before `Tk_GetColormap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:347: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:367: 
  syntax error before `Tk_GetGC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:369: 
  syntax error before `XGCValues'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:369: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:396: 
  syntax error before `Tk_GetPixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:396: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:397: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:414: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:419: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:421: 
  syntax error before `Colormap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:421: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:430: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:432: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:441: 
  syntax error before `Tk_InternAtom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:442: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:478: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:483: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:485: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:503: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:540: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:543: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:548: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:583: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:592: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:595: 
  syntax error before `Colormap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:598: 
  syntax error before `Visual'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:601: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:618: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:624: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:640: 
  syntax error before `Tk_AllocBitmapFromObj'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:642: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:648: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:650: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:693: 
  syntax error before `Tk_GetBitmapFromObj'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:694: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:696: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:697: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:763: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:766: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:779: 
  syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:787: 
  syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:794: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:798: 
  syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:814: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:842: 
  syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:844: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:845: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:847: 
  syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:852: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:853: 
  syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:856: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:858: 
  syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:863: 
  syntax error before `XSetWindowAttributes'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:865: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:866: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:871: 
  syntax error before `XWindowChanges'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:876: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:882: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:894: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:898: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:899: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:900: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:901: 
  syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:902: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:903: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:904: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:906: 
  syntax error before `Font'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:908: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:909: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:910: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:911: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:913: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:915: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:916: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:918: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:924: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:926: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:929: 
  syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:937: 
  syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:946: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:951: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:953: 
  syntax error before `Visual'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:956: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:957: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:960: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:973: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:975: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:976: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:983: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:994: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:995: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:996: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1007:
   syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1010:
   syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1011:
   syntax error before `Colormap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1012:
   syntax error before `Visual'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1013:
   syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1019:
   syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1020:
   syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1026:
   syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1028:
   syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1042:
   syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1063:
   syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1064:
   syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1068:
   syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1070:
   syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1072:
   syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1073:
   syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkDecls.h:1077:
   syntax error before `Pixmap'
  In file included 
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:18,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:16:
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:46: 
  syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:50: 
  syntax error before `Window'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:50: 
  `Window' declared as function returning a function
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:50: 
  warning: parameter names (without types) in function 
  declaration
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:53: 
  syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:62: 
  syntax error before `TkClassCreateProc'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:84: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:118: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:122: 
  syntax error before `Time'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:162: 
  syntax error before `KeyCode'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:221: 
  syntax error before `Font'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:388: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:421: 
  syntax error before `Atom'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:435: 
  syntax error before `XID'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:498: 
  field `warpWindow' declared as a function
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:645: 
  syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:650: 
  syntax error before `Visual'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:653: 
  field `window' declared as a function
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:703: 
  syntax error before `XWindowChanges'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:707: 
  syntax error before `XSetWindowAttributes'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:814: 
  syntax error before `Pixmap'
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:871: 
  syntax error before `*'
  In file included 
  from /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:87
  8,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:18,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:16:
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:46
  : syntax error before `XPoint'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:51
  : syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:57
  : syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:81
  : syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:91
  : syntax error before `TkCurrentTime'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:91
  : warning: data definition has no type or storage 
  class
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:98
  : syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:10
  5: syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:11
  9: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:12
  2: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:14
  7: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:17
  5: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:18
  2: syntax error before `keysym'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:19
  2: syntax error before `XPoint'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:23
  9: `TkpMakeWindow' declared as function returning a 
  function
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:24
  6: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:25
  9: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:27
  1: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:27
  3: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:28
  0: syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:28
  7: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:29
  1: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:30
  1: syntax error before `TkStringToKeysym'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:30
  1: warning: data definition has no type or storage 
  class
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:31
  9: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:36
  4: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:46
  9: syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:47
  6: syntax error before `KeySym'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:47
  8: syntax error before `TkpGetKeySym'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:47
  9: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:47
  9: warning: data definition has no type or storage 
  class
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:48
  9: syntax error before `XPoint'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:49
  1: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:49
  4: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:49
  9: syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:50
  2: syntax error before `Time'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:50
  5: syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:50
  7: syntax error before `Display'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:51
  1: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:51
  2: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:52
  1: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:53
  1: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:53
  3: syntax error before `keysym'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:53
  6: syntax error before `XPoint'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:55
  3: `tkpMakeWindow' declared as function returning a 
  function
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:55
  6: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:56
  0: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:56
  4: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:56
  5: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:56
  6: syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:56
  8: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:57
  0: syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:57
  3: syntax error before `KeySym'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:58
  0: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:59
  6: syntax error before `XEvent'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:70
  2: syntax error before `GC'
  /usr/local/src/tk8.3.4/unix/../generic/tkIntDecls.h:70
  4: syntax error before `KeySym'
  In file included 
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:18,
                   
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:16:
  /usr/local/src/tk8.3.4/unix/../generic/tkInt.h:1063: 
  syntax error before `XImage'
  In file included 
  from /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:16:
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:33: 
  syntax error before `Screen'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:38: 
  syntax error before `Colormap'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.h:52: 
  syntax error before `XColor'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:34: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:37: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_Alloc3DBorderFromObj':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:108: 
  warning: implicit declaration of function 
  `ScreenOfDisplay'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:108: 
  structure has no member named `display'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:108: 
  structure has no member named `screen'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:109: 
  structure has no member named `atts'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:109: 
  structure has no member named `colormap'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:138: 
  structure has no member named `display'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:138: 
  structure has no member named `screen'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:139: 
  structure has no member named `atts'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:139: 
  structure has no member named `colormap'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_Get3DBorder':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:194: 
  syntax error before `gcValues'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:195: 
  `XColor' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:195: 
  (Each undeclared identifier is reported only once
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:195: 
  for each function it appears in.)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:195: 
  `bgColorPtr' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:195: 
  warning: statement with no effect
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:196: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:198: 
  `dispPtr' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:209: 
  structure has no member named `display'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:209: 
  structure has no member named `screen'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:210: 
  structure has no member named `atts'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:210: 
  structure has no member named `colormap'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:232: 
  structure has no member named `screen'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:232: 
  structure has no member named `display'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:233: 
  structure has no member named `visual'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:233: 
  structure has no member named `visual'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:235: 
  structure has no member named `colormap'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:235: 
  structure has no member named `atts'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:238: 
  structure has no member named `bgColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:239: 
  structure has no member named `darkColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:240: 
  structure has no member named `lightColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:241: 
  structure has no member named `shadow'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:241: 
  `None' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:242: 
  structure has no member named `bgGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:243: 
  structure has no member named `darkGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:244: 
  structure has no member named `lightGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:255: 
  `gcValues' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:255: 
  structure has no member named `bgColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:256: 
  structure has no member named `bgGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:256: 
  `GCForeground' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:191: 
  warning: `hashPtr' might be used uninitialized in 
  this function
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_Draw3DRectangle':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:283: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: At top 
  level:
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:351: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:353: 
  warning: return-type defaults to `int'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_3DBorderColor':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:355: 
  structure has no member named `bgColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:356: 
  warning: control reaches end of non-void function
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: At top 
  level:
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:375: 
  syntax error before `Tk_3DBorderGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:376: 
  warning: return-type defaults to `int'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_3DBorderGC':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:384: 
  structure has no member named `lightGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:384: 
  `None' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:388: 
  structure has no member named `bgGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:390: 
  structure has no member named `lightGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:392: 
  structure has no member named `darkGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:401: 
  `GC' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:401: 
  syntax error before `None'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:402: 
  warning: control reaches end of non-void function
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_Free3DBorder':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:428: 
  `Display' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:428: 
  `display' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:428: 
  warning: implicit declaration of function 
  `DisplayOfScreen'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:428: 
  structure has no member named `screen'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:429: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:436: 
  `prevPtr' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:438: 
  structure has no member named `bgColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:439: 
  structure has no member named `bgColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:441: 
  structure has no member named `darkColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:442: 
  structure has no member named `darkColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:444: 
  structure has no member named `lightColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:445: 
  structure has no member named `lightColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:447: 
  structure has no member named `shadow'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:447: 
  `None' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:448: 
  structure has no member named `shadow'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:450: 
  structure has no member named `bgGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:451: 
  structure has no member named `bgGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:453: 
  structure has no member named `darkGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:454: 
  structure has no member named `darkGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:456: 
  structure has no member named `lightGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:457: 
  structure has no member named `lightGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_SetBackgroundFromBorder':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:600: 
  structure has no member named `bgColorPtr'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_Draw3DPolygon':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:752: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:754: 
  syntax error before `XPoint'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:766: 
  syntax error before `poly'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:768: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:770: 
  syntax error before `gc'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:772: 
  `Display' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:772: 
  `display' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:772: 
  structure has no member named `display'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:774: 
  structure has no member named `lightGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:774: 
  `None' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:800: 
  `p1Ptr' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:800: 
  subscripted value is neither array nor pointer
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:801: 
  `p2Ptr' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:801: 
  subscripted value is neither array nor pointer
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:847: 
  subscripted value is neither array nor pointer
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:847: 
  warning: left-hand operand of comma expression has no 
  effect
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:847: 
  warning: value computed is not used
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:848: 
  warning: left-hand operand of comma expression has no 
  effect
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:859: 
  `newB1' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:860: 
  `newB2' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:862: 
  `poly' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:865: 
  `b1' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:865: 
  `b2' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:897: 
  `perp' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:900: 
  `c' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:901: 
  `shift1' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:902: 
  `shift2' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:916: 
  `gc' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:916: 
  structure has no member named `lightGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:918: 
  structure has no member named `darkGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:920: 
  warning: implicit declaration of function 
  `XFillPolygon'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:920: 
  `Convex' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:921: 
  `CoordModeOrigin' undeclared (first use in this 
  function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:848: 
  warning: value computed is not used
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_Fill3DRectangle':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:960: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:994: 
  warning: implicit declaration of function 
  `XFillRectangle'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:994: 
  structure has no member named `display'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:994: 
  structure has no member named `bgGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: In 
  function `Tk_Fill3DPolygon':
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1025: 
  syntax error before `Drawable'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1027: 
  syntax error before `XPoint'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1041: 
  structure has no member named `display'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1041: 
  structure has no member named `bgGC'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1042: 
  `Complex' undeclared (first use in this function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1042: 
  `CoordModeOrigin' undeclared (first use in this 
  function)
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c: At top 
  level:
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1093: 
  syntax error before `XPoint'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1094: 
  `p2Ptr' used prior to declaration
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1094: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1099: 
  syntax error before `*'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1099: 
  warning: data definition has no type or storage class
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:1101: 
  syntax error before `{'
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:35: 
  warning: `Intersect' declared `static' but never 
  defined
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:36: 
  warning: `InitBorderObj' used but never defined
  /usr/local/src/tk8.3.4/unix/../generic/tk3d.c:38: 
  warning: `ShiftLine' declared `static' but never 
  defined
  *** Error code 1

  Stop in /usr/local/src/tk8.3.4/unix.
  aleph# 


tkt_uuid: 520520ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Works For Me
title: test suite failures
comment:
  platform: sparc solaris 2.6
  Compiler: Sun's C compiler
  cc: Sun WorkShop 6 2000/06/19 C 5.1 Patch 109491-02
  Tcl and Tk from the activestate cvs as of Feb 20, 00:05
  2002

  I did a make distclean then a 
  configure --prefix=/usr/tcl84 --enable-symbols
  in the Tcl directory, then a make, and a make test
  that passed all tests, then a make install.

  I then moved to the tk directory,
  did a make distclean then a 
  configure --prefix=/usr/tcl84 --enable-symbols
  and then a make and make test .  I got these errors

  filebox.test

  ==== filebox-3.2 tk_getSaveFile command FAILED
  ==== Contents of test case:

                  ToPressButton $parent ok
                  set choice [$command -title "Press Ok"
  -filetypes $filters($x) -
  parent $parent -initialfile $fileName -initialdir
  $fileDir]
              
  ---- Result was:
  /vol/tclsrcsol/tcl84/tk/unix/12x 455.txt
  ---- Result should have been:
  /vol/tclsrcsol/tcl84/tk/unix/12x 455
  ==== filebox-3.2 FAILED

  ==== filebox-3.3 tk_getSaveFile command FAILED
  ==== Contents of test case:

                  ToPressButton $parent ok
                  set choice [$command -title "Press Ok"
  -filetypes $filters($x) -
  parent $parent -initialfile $fileName -initialdir
  $fileDir]
              
  ---- Result was:
  /vol/tclsrcsol/tcl84/tk/unix/12x 455.txt
  ---- Result should have been:
  /vol/tclsrcsol/tcl84/tk/unix/12x 455
  ==== filebox-3.3 FAILED

  focus.test

  ==== focus-5.1 ChangeXFocus procedure, don't take focus
  unless have it FAILED
  ==== Contents of test case:

      focusSetup
      focus -force .t
      update
      set result [focus]
      send [dobg {tk appname}] {focus -force .; update}
      lappend result [focus]
      focus .t.b2
      update
      lappend result [focus]

  ---- Result was:
  .t .t {}
  ---- Result should have been:
  .t {} {}
  ==== focus-5.1 FAILED


  listbox.test

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

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

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


  unixWm.test

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

      eval destroy [winfo children .]
      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:
  {} {} {} {} {} {} {} {}
  ---- Result should have been:
  {} {} .t {} .t2 .t2 {} .t
  ==== unixWm-50.1 FAILED

  ==== unixWm-50.2 Tk_CoordsToWindow procedure, finding a
  toplevel, y-coords and o
  verrideredirect FAILED
  ==== Contents of test case:

      eval destroy [winfo children .]
      toplevel .t -width 300 -height 400 -bg yellow
      wm geom .t +0+50
      tkwait visibility .t
      toplevel .t2 -width 100 -height 80 -bg blue
      wm overrideredirect .t2 1
      wm geom .t2 +100+200
      tkwait visibility .t2
      raise .t2
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      set y2 [winfo rooty .t2]
      list [winfo containing [expr $x +150] 10]  [winfo
  containing [expr $x +150] 
  [expr $y - 1]]  [winfo containing [expr $x +150] $y] 
  [winfo containing [expr $x
   +150] [expr $y2 - 1]]  [winfo containing [expr $x
  +150] $y2]  [winfo containing
   [expr $x +150] [expr $y2 + 79]]  [winfo containing
  [expr $x +150] [expr $y2 + 8
  0]]  [winfo containing [expr $x +150] [expr $y + 450]]

  ---- Result was:
  {} {} {} {} .t2 .t2 {} {}
  ---- Result should have been:
  {} {} .t .t .t2 .t2 .t {}
  ==== unixWm-50.2 FAILED

  ==== unixWm-50.3 Tk_CoordsToWindow procedure, finding a
  toplevel with embedding 
  FAILED
  ==== Contents of test case:

      eval destroy [winfo children .]
      toplevel .t -width 300 -height 400 -bg blue
      wm geom .t +0+50
      frame .t.f -container 1
      place .t.f -x 150 -y 50
      tkwait visibility .t.f
      setupbg
      dobg "
          wm withdraw .
          toplevel .x -width 100 -height 80 -use [winfo
  id .t.f] -bg yellow
          tkwait visibility .x"
      set result [dobg {
          set x [winfo rootx .x]
          set y [winfo rooty .x]
          list [winfo containing [expr $x - 1] [expr $y +
  50]]  [winfo containing 
  $x [expr $y +50]]
      }]
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      lappend result [winfo containing [expr $x + 200]
  [expr $y + 49]]  [winfo con
  taining [expr $x + 200] [expr $y +50]]

  ---- Result was:
  {} {} {} {}
  ---- Result should have been:
  {} .x .t .t.f
  ==== unixWm-50.3 FAILED

  ==== unixWm-50.4 Tk_CoordsToWindow procedure, window in
  other application FAILED
  ==== Contents of test case:

      catch {destroy .t}
      catch {interp delete slave}
      toplevel .t -width 200 -height 200 -bg green
      wm geometry .t +0+0
      tkwait visibility .t
      interp create slave
      load {} Tk slave
      slave eval {wm geometry . 200x200+0+0; tkwait
  visibility .}
      set result [list [winfo containing 100 100]  [slave
  eval {winfo containing 1
  00 100}]]
      interp delete slave
      set result

  ---- Result was:
  {} {}
  ---- Result should have been:
  {} .
  ==== unixWm-50.4 FAILED

  ==== unixWm-50.5 Tk_CoordsToWindow procedure, handling
  menubars FAILED
  ==== Contents of test case:

      eval destroy [winfo children .]
      toplevel .t -width 300 -height 400 -bd 2 -relief
  raised
      frame .t.f -width 150 -height 120 -bg green
      place .t.f -x 10 -y 150
      wm geom .t +0+50
      frame .t.menu -width 100 -height 30 -bd 2 -relief
  raised
      frame .t.menu.f -width 40 -height 20 -bg purple
      place .t.menu.f -x 30 -y 10
      testmenubar window .t .t.menu
      tkwait visibility .t.menu
      update
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      list [winfo containing $x [expr $y - 31]]  [winfo
  containing $x [expr $y - 3
  0]]  [winfo containing [expr $x + 50] [expr $y - 19]] 
  [winfo containing [expr $
  x + 50] [expr $y - 18]]  [winfo containing [expr $x +
  50] $y]  [winfo containing
   [expr $x + 11] [expr $y + 152]]  [winfo containing
  [expr $x + 12] [expr $y + 15
  2]]

  ---- Result was:
  {} {} {} {} {} {} {}
  ---- Result should have been:
  {} .t.menu .t.menu .t.menu.f .t .t .t.f
  ==== unixWm-50.5 FAILED

  ==== unixWm-50.6 Tk_CoordsToWindow procedure, embedding
  within one app. FAILED
  ==== Contents of test case:

      eval destroy [winfo children .]
      toplevel .t -width 300 -height 400 -bg orange
      wm geom .t +0+50
      frame .t.f -container 1
      place .t.f -x 150 -y 50
      tkwait visibility .t.f
      toplevel .t2 -width 100 -height 80 -bg green -use
  [winfo id .t.f]
      tkwait visibility .t2
      update
      set x [winfo rootx .t]
      set y [winfo rooty .t]
      list [winfo containing [expr $x +149] [expr $y +
  80]]  [winfo containing [ex
  pr $x +150] [expr $y +80]]  [winfo containing [expr $x
  +249] [expr $y +80]]  [wi
  nfo containing [expr $x +250] [expr $y +80]]

  ---- Result was:
  {} {} {} {}
  ---- Result should have been:
  .t .t2 .t2 .t
  ==== unixWm-50.6 FAILED
  ==== unixWm-50.7 Tk_CoordsToWindow procedure, more
  basics FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 300 -height 400 -bg green
      wm geom .t +0+0
      frame .t.f -width 100 -height 200 -bd 2 -relief
  raised
      place .t.f -x 100 -y 100
      frame .t.f.f -width 100 -height 200 -bd 2 -relief
  raised
      place .t.f.f -x 0 -y 100
      tkwait visibility .t.f.f
      set x [expr [winfo rootx .t] + 150]
      set y [winfo rooty .t]
      list [winfo containing $x [expr $y + 50]]  [winfo
  containing $x [expr $y + 1
  50]]  [winfo containing $x [expr $y + 250]]  [winfo
  containing $x [expr $y + 350
  ]]  [winfo containing $x [expr $y + 450]]

  ---- Result was:
  {} {} {} {} {}
  ---- Result should have been:
  .t .t.f .t.f.f .t {}
  ==== unixWm-50.7 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:
  {} {} {} {} {}
  ---- Result should have been:
  .t .t.f .t.f.f .t {}
  ==== unixWm-50.8 FAILED

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

      catch {destroy .t}
      catch {destroy .t2}
      sleep 500           ;# Give window manager time to
  catch up.
      toplevel .t -width 200 -height 200 -bg green
      wm geometry .t +0+0
      tkwait visibility .t
      toplevel .t2 -width 200 -height 200 -bg red
      wm geometry .t2 +0+0
      tkwait visibility .t2
      set result [list [winfo containing 100 100]]
      wm iconify .t2
      lappend result [winfo containing 100 100]

  ---- Result was:
  {} {}
  ---- Result should have been:
  .t2 .t
  ==== unixWm-50.9 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:
  {} {}
  ---- Result should have been:
  .t.f .t
  ==== unixWm-50.10 FAILED

  ==== unixWm-51.6 TkWmRestackToplevel procedure, window
  to be stacked isn't mappe
  d FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t -width 200 -height 200 -bg green
      wm geometry .t +0+0
      tkwait visibility .t
      catch {destroy .t2}
      toplevel .t2 -width 200 -height 200 -bg red
      wm geometry .t2 +0+0
      winfo containing 100 100

  ---- Result was:

  ---- Result should have been:
  .t
  ==== unixWm-51.6 FAILED

  ==== unixWm-51.7 TkWmRestackToplevel procedure, other
  window isn't mapped FAILED
  ==== Contents of test case:

      foreach w {.t .t2 .t3} {
          catch {destroy $w}
          toplevel $w -width 200 -height 200 -bg green
          wm geometry $w +0+0
      }
      raise .t .t2
      update
      set result [list [winfo containing 100 100]]
      lower .t3
      lappend result [winfo containing 100 100]

  ---- Result was:
  {} {}
  ---- Result should have been:
  .t3 .t
  ==== unixWm-51.7 FAILED

  util.test
  visual.test
  visual_bb.test
  winButton.test
  winClipboard.test
  winDialog.test
  winFont.test
  winMenu.test
  winSend.test
  skipping: Windows only tests...
  winWm.test
  window.test
  winfo.test

  ==== winfo-4.5 "winfo containing" command FAILED
  ==== Contents of test case:

      winfo containing [winfo rootx .t.f] [winfo rooty
  .t.f]

  ---- Result was:

  ---- Result should have been:
  .t.f
  ==== winfo-4.5 FAILED

  ==== winfo-13.4 [winfo containing] with embedded
  windows FAILED
  ==== Contents of test case:

      MakeEmbed
      button .b
      pack .b -expand yes -fill both
      update
      set z [string compare  [winfo containing [winfo
  rootx .emb.b] [winfo rooty .
  emb.b]] .emb.b]
      catch {destroy .con}
      catch {destroy .emb}
      set z

  ---- Result was:
  -1
  ---- Result should have been:
  0
  ==== winfo-13.4 FAILED

  wm.test

  ==== wm-stackorder-2.2  FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t ; update
      raise .
      wm stackorder .

  ---- Result was:
  . .t
  ---- Result should have been:
  .t .
  ==== wm-stackorder-2.2 FAILED

  ==== wm-stackorder-2.3  FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t ; update
      catch {destroy .t2}
      toplevel .t2 ; update
      raise .
      raise .t2
      wm stackorder .

  ---- Result was:
  . .t .t2
  ---- Result should have been:
  .t . .t2
  ==== wm-stackorder-2.3 FAILED

  ==== wm-stackorder-2.4  FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t ; update
      catch {destroy .t2}
      toplevel .t2 ; update
      raise .
      lower .t2
      wm stackorder .

  ---- Result was:
  .t2 . .t
  ---- Result should have been:
  .t2 .t .
  ==== wm-stackorder-2.4 FAILED

  ==== wm-stackorder-2.5  FAILED
  ==== Contents of test case:

      catch {destroy .parent}
      toplevel .parent ; update
      catch {destroy .parent.child1}
      toplevel .parent.child1 ; update
      catch {destroy .parent.child2}
      toplevel .parent.child2 ; update
      catch {destroy .extra}
      toplevel .extra ; update
      raise .parent
      lower .parent.child2
      wm stackorder .parent

  ---- Result was:
  .parent.child2 .parent .parent.child1
  ---- Result should have been:
  .parent.child2 .parent.child1 .parent
  ==== wm-stackorder-2.5 FAILED

  ==== wm-stackorder-4.3 wm stackorder isabove|isbelow
  FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t ; update
      raise .
      wm stackorder .t isa .

  ---- Result was:
  1
  ---- Result should have been:
  0
  ==== wm-stackorder-4.3 FAILED

  ==== wm-stackorder-4.4 wm stackorder isabove|isbelow
  FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t ; update
      raise .
      wm stackorder .t isb .

  ---- Result was:
  0
  ---- Result should have been:
  1
  ==== wm-stackorder-4.4 FAILED

  ==== wm-stackorder-5.1 a menu is not a toplevel FAILED
  ==== Contents of test case:

      catch {destroy .t}
      toplevel .t
      menu .t.m -type menubar
      .t.m add cascade -label "File"
      .t configure -menu .t.m
      update
      raise .
     wm stackorder .

  ---- Result was:
  . .t
  ---- Result should have been:
  .t .
  ==== wm-stackorder-5.1 FAILED

  xmfbox.test


tkt_uuid: 521356ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 84. Unix Build
priority: 9 Immediate
foundin: None
resolution: Accepted
title: package index for loadable Tk
comment:
  This patch to the unix Makefile.in causes the
  'make install-binaries' target to create and
  install a suitable pkgIndex.tcl file so that
  Tk is installed as a loadable Tcl package
  "out of the box".


tkt_uuid: 521436ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Fixed
title: panedwindow patch
comment:
  As mentionned ealier in comp.lang.tcl,
  [panedwindow paneconfigure] lacks an "objc"
  checking in function PanedWindowWidgetObjCmd().
  Also, return statements in this function makes
  miss the call to Tcl_Release() at the end of
  the function.

  The patch attached resolves both these issue.


tkt_uuid: 521466ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Duplicate
title: panedwindow-frame-text sizing trouble
comment:
  When I run the vertical panedwindow demo (which I've
  checked into CVS and intend to have distributed with
  the rest of Tk) the widgets inside the pane do not show
  up until after the window as a whole is resized.  No
  problem is present in the horizontal panedwindow demo.


tkt_uuid: 521557ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Works For Me
title: send-15.1 fails
comment:
  starting today, I see this failure during
  'make test':

  ==== send-15.1 UpdateCommWindow procedure FAILED
  ==== Contents of test case:

      set x [list [testsend prop comm TK_APPLICATION]]
      newApp "" t_s_1 Test
      send t_s_1 wm withdraw .
      newApp "" t_s_2 Test
      send t_s_2 wm withdraw .
      lappend x [testsend prop comm TK_APPLICATION]
      interp delete t_s_1
      lappend x [testsend prop comm TK_APPLICATION]
      interp delete t_s_2
      lappend x [testsend prop comm TK_APPLICATION]

  ---- Result was:
  {tktest {tk #5} {tk #3}} {t_s_2 t_s_1 tktest {tk #5}
  {tk #3}} {t_s_2 tktest {tk #5} {tk #3}} {tktest {tk #5}
  {tk #3}}
  ---- Result should have been:
  tktest {t_s_2 t_s_1 tktest} {t_s_2 tktest} tktest
  ==== send-15.1 FAILED


tkt_uuid: 521560ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 61. Safe Tk
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: safe test failures
comment:
  starting today, almost all tests in
  tests/safe.test fail with the error

  "Can't find a usable tk.tcl in the following
  directories:
      {$p(:20:)}"


tkt_uuid: 521946ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 3 Low
foundin: obsolete: 8.4a4
resolution: None
title: Set widget pathName to NULL on destroy
comment:
  A detailed description of what lead up to this
  patch can be found here:


  http://groups.google.com/groups?hl=en&threadm=3C75D7AB.C67D965B%40nospam.com&rnum=1&prev=/groups%3Fq%3DTk_Window%2BMo%2Bgroup:comp.lang.tcl%26hl%3Den%26scoring%3Dr%26selm%3D3C75D7AB.C67D965B%2540nospam.com%26rnum%3D1

  I ran the Tk test suite with this patch applied
  and it did not seem to cause any problems.

  Another approach might be to copy the window
  path name and create another function to
  "really" free up a Tk_FakeWin pointer after
  the last call to Tcl_Release(). See the
  comp.lang.tcl post for more about that option.


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

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

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

  bad event type or keysym "..."

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

  Line 379, library/msgbox.tcl:

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

  could be changed to:

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


tkt_uuid: 523593ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 69. Events
priority: 2
foundin: None
resolution: Fixed
title: bind(n) manpage needs more detail
comment:
  On comp.lang.tcl, Donal Fellows wrote:
  --
  The [bind] manpage really assumes a deep knowledge of
  X, and there are many of
  its mysteries that I am still a long way from
  penetrating (all the Focus related
  stuff is particularly gnostic...)  Documentation
  improvements (particularly ones
  that state when an event might be generated by the
  system) would be gladly
  accepted...
  --

  In particular, bind(n) states:

       Most of the above events have the same fields 
  and  behaviors 
       as  events  in the X Windowing system.  You can
  find
       more detailed descriptions of these events in any
  X window
       programming  book.

  This section should be replaced with an actual detailed
  description,
  for the benefit of those who don't want to buy a book
  on X :-)


tkt_uuid: 525111ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Works For Me
title: Bug in menu delete
comment:
  The followin code shows a bug in the windows menu
  implementation:

  menu .menu

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

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


tkt_uuid: 525728ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: None
title: window resize handles hiccup
comment:
  On m.s. windows the resize handles seem to have 
  a "hole" where they suddenly change back to the 
  original pointer (e.g. an arrow) as you move the mouse 
  over the left, right, or bottom edge (but strangely, 
  not the top edge - i.e. at the title). Also the 
  diagonal lower right corner.

  To duplicate, simply run wish so you have the . window 
  open. No code needed. However, this occurs on all 
  toplevel windows.

  Now, move the mouse left and right over the right hand 
  border. 

  You will see the cursor change to <--> then blink back 
  to the pointer, then the <--> a second time, then 
  finally back to the cursor. This happens on all tcl/tk 
  windows maybe 50% of the time. 

  This makes it difficult to grab hold of the windows 
  edge to resize it.


  In all other windows apps (i.e. not tcl/tk), this does 
  not occur.

  But tcl/tk seems to have a hole in the middle, where 
  it might be losing focus or something. Often if you 
  have the mouse positioned to resize, then press the 
  mouse button, the slight movement (say 1 pixel) is 
  enough to have the cursor change before you can "grab" 
  it.


tkt_uuid: 525778ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Duplicate
title: No flush of stdout on [exit]
comment:
  First noticed this problem as the absence
  of a summary at the end of the Tk test suite
  on Solaris CDE.  The stdout channel (stderr too)
  is not being flushed on [exit] from wish.

  # FILE: test.tcl
  for {set i 0} {$i < [lindex $argv 0]} {incr i} {
    puts $i
  }
  exit

  $ wish8.3 test.tcl 5
  0
  1
  2
  3
  4
  $ wish8.4 test.tcl 5
  <no output>

  $ wish8.3 test.tcl 500
  0
  ...
  499
  $ wish8.4 test.tcl 500
  0
  ...
  474
  $


  Very strange.


tkt_uuid: 526180ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: None
resolution: Invalid
title: Bad scroll on ListBox with MouseWheel
comment:
  Hello, 

  A user of my program send me a bug with his Microsoft 
  mouse with Wheel.

  When a sample list is displayed, with no binding at 
  all, the list scroll normaly when he turn the Wheel. 
  But when he click on it (not turn but click) and drag 
  up or down his mouse, the list scroll in the bad 
  direction 

  I suppose that it's a problem in the default binding 
  of the listbox. I don't have this kind of mouse so I 
  can't test, but do you know something about this 
  problem ?... 

  Thanks, Etienne 


tkt_uuid: 526209ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 70. Event Loop
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: semi-random event-* test failures
comment:
  The event-* tests seem to fail for semi-random
  reasons.  I've figured out at least some of
  a few of the reasons.  Leaving it to Mo to find
  solutions.

  Occasionally, one gets the error:

  can't read "y1": no such variable

  This happens when [$text bbox $ind] returns an empty
  list, and according to the [text] docs, that happens
  when the index $ind of $text is not visible.  I
  believe that if by chance windows overlap during the
  test in such a way that the $ind of $text is obscured,
  you get this error.

  I also see the tests event-click-drag-1.2 and
  event-double-click-drag-1.2 fail on occasion.
  When they fail, only the first character of
  the test string has been "typed in" to the entry.
  This is because that entry widget has lost the
  focus.  This happens when the window manager
  is configured to have "focus follows mouse" and
  it just happens that the mouse cursor was in the text
  widget of the prior test, but is currently not
  in the entry widget of the current test (because
  the entry is smaller than the text).  Because the
  mouse cursor has "moved out" of the window (even
  though it is still), the focus is shifted to whatever
  window currently lies below the mouse, and the
  "typing" events are lost.

  This can happen even with the mouse stationary.
  It is easy to induce even more errors if one moves
  the mouse around during the event-* tests in a
  window manager configured for "focus follows mouse".


tkt_uuid: 526791ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Fixed
title: canvas bug - MS Windows
comment:
  I get the following error while creating images on a 
  canvas: "WISH83 has caused an error in TK83.DLL.  
  WISH83 will now close."  I get the error in MS Windows 
  only (Me, NT, 2000).  I have attached a script and ppm 
  file to demonstrate the error.  This script runs fine 
  in Linux but gets the above error in Windows.


tkt_uuid: 526823ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: Mac OS X Tk 8.4a4:Clicking a checkbutton
comment:
  Mac OS X Tk 8.4a4:Clicking a checkbutton brings an 
  error dialog saying "Can't read Priv(repeated): no 
  such variable".  

  How to reproduce:
  Enter the following scrpt on Console"
  checkbutton .cb -text "Hello"
  pack .cb

  Then click the button on Wish Shell.

  Here is the error log.
  can't read "Priv(repeated)": no such variable
  can't read "Priv(repeated)": no such variable
      while executing
  "if { $Priv(repeated) == 0 } {
          uplevel #0 [list $w invoke]
          }"
      (procedure "tk::ButtonUp" line 18)
      invoked from within
  "tk::ButtonUp .dummy.gui.options.printidentical"
      (command bound to event)

  System I'm using is Mac OS X 10.1.3.


tkt_uuid: 527921ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Invalid
title: spinbox not readonly
comment:
  Setting the spinbox readonly option does not disable
  buttons or keyboard up/down
  (8.4a4 Linux Mandrake 8.1 and Windows 2000 ActiveTcl
  8.4.0.1 b2)


tkt_uuid: 528330ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 48. Geometry Management
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: None
title: geometry X resource ignored
comment:
  > xrdb -query | grep Wish
  Wish.geometry:  400x300
  > wish
  Wish
  % tk appname
  wish
  % option get . geometry Geometry
  400x300
  % wm geometry .
  200x200+813+25
  % winfo geometry .
  200x200+813+25

  The window should be positioned according to its
  geometry resource.

  Workaround:

  Put this at the start of the script:

  set g [option get . geometry Geometry]
  if { $g != "" } { wm geometry . $g }


tkt_uuid: 528441ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 9 Immediate
foundin: obsolete: 8.4a4
resolution: Fixed
title: Tk builds incorrectly under VC++5.2 (focus, click bugs)
comment:
  The changes introduced by hobbs on Feb 26th to 
  tkText.c mean that the cursor doesn't blink at all 
  when a text widget is first created, under some 
  circumstances, and this then seems to break clicking 
  in the widget and making a selection.

  See, for example, the 'basic editable text' Tk demo, 
  and try out suggestion number '3'.  The widget doesn't 
  appear to take the focus (even thought it seems to 
  already have it), until the focus is manually moved to 
  a different window and back again.

  Vince.


tkt_uuid: 528464ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Cut/Paste broken on Mac OSX
comment:
  When using the native OSX port of tk, I find that I cannot paste data 
  from other applications. I suspect this may have something to do 
  with encodings as what I get pasted is gibberish.


tkt_uuid: 528892ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 4
foundin: None
resolution: Out of Date
title: Argv has value on startup
comment:
  When you start the OSX build of tk, argc is set to 1 and argv has a value 
  which was not provided by me! The value looks like -psn_0_1048577 
  (probably a process id of some kind as it changes every run)


tkt_uuid: 528893ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Out of Date
title: OSX tk crashes
comment:
  This is just to log the fact that OSX tk crashes when running my 
  mercator program. As yet I have not tracked down the cause so cannot 
  give more details, however, I did find an OSX console message about 
  an attempt to free already free storage so that may be the cause. I 
  will investigate further and see if I can get more details.


tkt_uuid: 530212ffffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Fixed
title: Bad Window Path Name in tkMenuFind
comment:
  Attached is a BWidget script that reliably reproduces a bug in Tk (verified up to 8.3.4).
  This bug happens if a menu item is invoked through
  an accelerator, and if the main window (the one
  containing the menu) loses focus while the command
  bound to the menu item is in progress: the
  attached script uses a modal dialog to
  reproduce this condition.

  The error is:

  bad window path name ""
      while executing
  "winfo toplevel [focus"
      (procedure "tkMenuFind" line 8)
      invoked from within
  "tkMenuFind [winfo toplevel $w] $char"
      (procedure "tkTraverseToMenu" line 15)
      invoked from within
  "tkTraverseToMenu . o"
      (command bound to event)

  Here is an analysis of the problem from Joe
  English on comp.lang.tcl; see the thread for
  http://groups.google.com/groups?selm=slrna9111j.ug.fp%40rose.fpx.de

   User presses <Alt-Key-o>

   BWidgets has bound <Alt-Key-o> to
   [$menu invoke $n], where $menu is the "&File"
   menu and $n is the "Open..." entry.

   This evaluates the entry's -command, in this
   case FileOpen

   FileOpen creates a new dialog with a global
   grab, then calls [vwait ::mutex]

   User presses the 'Close' button, which sets
   ::mutex

   FileOpen returns from the vwait, releases the
   grab, and destroys the dialog
   
   Remember, we're still processing the
   <Alt-Key-o> binding on "."

   [$menu invoke $n] returns.

   Now, Tk's binding for <Alt-KeyPress> fires:
   bind all <Alt-KeyPress> {
     tk::TraverseToMenu %W %A }
   (This is from when the user pressed Alt-Key-o
   many steps ago)

   tkTraverseToMenu calls [tk::MenuFind "." "o"]

   tk::MenuFind executes this loop:

  | set windowlist [winfo child $w]
  | foreach child $windowlist {
  |  # Don't descend into other toplevels.
  |  if {[string compare [winfo toplevel [focus]]
  >>>--------------------^^^^^^^^^^^^^^^^^^^^^^^^
       [winfo toplevel $child]]} {
  |    continue
  |  }


  I believe the undersharkfinned part is a bug.
  It should be [winfo toplevel $w], not [winfo
  toplevel [focus]].

  Under most circumstances, [winfo toplevel [focus]]
  will be the same as [winfo toplevel $w] when this
  code path is executed.  But in Frank's test case,
  because of a [vwait] call indirectly invoked by a
  keyboard binding, the focus widget gets lost
  between the time the key is pressed and
  [tkMenuFind] gets called.

  But I still think tk::MenuFind is incorrect.
  Arguably, so is BWidget for not "break"ing in the
  menu accelerator bindings.  These three bugs,
  relatively harmless by themselves, conspire to
  cause the problem.


tkt_uuid: 530491ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: None
resolution: Invalid
title: menu -type menubar breaks kbd navigation
comment:
  Keyboard navigation to menus with <Alt-Keypress> raises
  an error if the menu is configured with -type menubar,
  as the following script demonstrates:

  #--cut here
  package require Tk
  menu .menubar -type menubar
  menu .file
  .file add command -label Exit -underline 1 -command
  [list destroy .]
  .menubar add cascade -label File -underline 0 -menu
  .file
  . configure -menu .menubar

  pack [label .l -text "Press Alt-F"] \
          -expand true -fill both -padx 200 -pady 200

  #-- cut here

  This raises an error:

  grab failed: window not viewable
  grab failed: window not viewable
      while executing
  "grab -global $w"
      (procedure "tk::TraverseToMenu" line 21)
      invoked from within
  "tk::TraverseToMenu . f"
      (command bound to event)

  Without '-type menubar',  keyboard navigation works OK.


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

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

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

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

  Best wishes ZB


tkt_uuid: 531658ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: None
title: ButtonRelease on Grab Window
comment:
  I have a problem with the ButtonRelease bind on a 
  window that has the grab if I move off the window with 
  the button depressed and then release it.
  Platform: Windows 2000

  Steps to reproduce:
  1. Create a window:

      toplevel .testWindow -class Toplevel
      wm focusmodel .testWindow passive
      wm geometry .testWindow 406x312+254+250
      wm title .testWindow "Login"
      entry .testWindow.userId
      place .testWindow.userId -in .testWindow \
            -x 145 -y 80
      grab .testWindow
      # Done

  NOTE: You must make sure the window has the grab.

  2. Place the cursor in the entry widget and type
     the "123456789"

  3. Hold down the LMB and highlight what you just typed.
     Without releasing the LMB, move the mouse over 
     to the Windows Desktop and then release the LMB.

  4. Move the mouse back over the .testWindow. TK acts 
     like the LMB is still depressed. If you start
     typing with everything highlight, input appears to
     the left because it acts like you have the first
     character highlighted.


tkt_uuid: 532022ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 51. [place]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: place info -in not returned in parent
comment:
  The 'place info' command should return all
  configuration options for a widget managed by 'place'.
  If the widget is 'place'd in its parent (the default)
  the 'place info' does not return the '-in widget'
  option-value pair in the list of returned values. This
  is inconsistent with the pack and grid managers. It
  does however return this option if the widget is
  'place'd in a widget other than its parent.

  Workaround:
  set w [button .b]
  place $w -x 0 -y 0 -width 50 -height 20
  set info(-in) [winfo parent $w]
  array set info [place info $w]
  set place [array get info]
  place forget $w
  % eval place $w $place


tkt_uuid: 532120ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 02. Appearance
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: sunken widget bordercolors from parent
comment:
  I think that 'sunken' widgets (e.g. entry, text,
  listbox, spinbox, others?) should set their
  bordercolors (hilight, shadow) relative to their
  parent, or rather their geometry master. For example,
  if you pack an entry, with a white background, in a
  blue frame, the hilight/shadow colors should be shades
  of blue, not gray.


tkt_uuid: 532422ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: None
resolution: None
title: add -padx and -pady options to menubars
comment:
  This patch adds -padx and -pady options to the [menu]
  command. They replace the hardcoded values for the
  spacing around the entries in menus used as menubars.
  The defaults for this options are the same as the
  hardcoded values before.

  Maybe the same options could be used to replace the
  also hardcoded MENU_MARGIN_WIDTH and
  MENU_DIVIDER_HEIGHT (see top of tkUnixMenu.c), but they
  need different defaults, therefore I left that out for
  the moment.


tkt_uuid: 532540ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 54. [console]
priority: 7 High
foundin: None
resolution: None
title: Normalize [console]
comment:
  On Windows and Mac, wish (not Tk!) includes a 
  [console] command for controlling a console to
  which it redirects Tcl's stdout and stderr channels.

  When [package require Tk] brings Tk into a tclsh,
  there is no [console] and there is no console.

  On Unix, there is no console and no [console].

  It is simple to add [console] to wish on Unix, by
  enabling the Tk_InitConsoleChannels in Tk_Main and
  adding a call to Tk_CreateConsoleWindow in Tcl_AppInit.
  However, this has the effect of losing access to the
  real standard channels -- a big loss on Unix.

  On Windows, with the makefile.vc, one can build a
  wishc.exe program that behaves more like wish on
  Unix.  No [console] and use of the "real" standard
  channels of a DOS console.

  Because of all these variants it is somewhat
  unpleasant to write code that tries to use [console],
  with [catch]es or [if $tcl_platform...] all over the
  place.

  A revisions that normalized the availability and
  behavior of [console] would be welcome.


tkt_uuid: 534755ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: Invalid
title: compound queries via canvas find
comment:
  Please consider enhancing the canvas find subcommand 
  (as well as the addtag subcommand) to allow compound 
  searches.

  something like ".c find withtag SOME_TAG && 
  overlapping $x1 $y1 $x2 $y2 && below OTHER_TAG"

  would make it easier than 3 separate searches
  and then doing some wired list operations to get
  the same effect - for completeness, sytax should
  allow grouping and negation

  No patch at this point - just wishfull thinking,
  when I have some free time I might look into this 
  myself.


tkt_uuid: 535350ffffffffffffffffffffffffffffffffff
type: Patch
status: Deleted
subsystem: None
priority: 5 Medium
foundin: None
resolution: Works For Me
title: bgerror - wrong displaying window
comment:
  Hi,

  my problem is that: Vhen is invoked "bgerror",
  created window is separated from its content.

  URL of screenshots is:

  http://web.telecom.cz/WoodPrint/brerror1.png
  http://web.telecom.cz/WoodPrint/brerror2.png
  and after move window vith mouse
  http://web.telecom.cz/WoodPrint/brerror3.png

  Content of window is stiky on sceen and I dosenot
  move it.

  I found "woraround?", to comment line 245 
  in file bgerror.tcl

      set y [expr {([winfo screenheight .bgerrorDialog] -
  $height)/2 - \
              [winfo vrooty $parent]}]
      .bgerrorDialog configure -width $width
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      wm geometry .bgerrorDialog +$x+$y
      wm deiconify .bgerrorDialog

  OR execute it later

  after 1 .bgerrorDialog configure -width $width

  after this things work fine.

  Tanks for comments Michal <wohnivec@iol.cz>


tkt_uuid: 535541ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: None
resolution: Accepted
title: XFree86 Anti-Aliased text patches
comment:
  The following patches are what I received from Keith 
  Packard ( http://www.xfree86.org/~keithp/) that added 
  anti-aliased XFree86 text support to Tk on Unix.  It 
  did it by removing lots of other functionality 
  though.  From Keith:

  ----
  It's entirely a hack at some level.  When you deal 
  with TrueType fonts, 
  you can always get an ISO 10646 (UCS) encoding, so for 
  languages well 
  served using that as a glyph encoding things are 
  really easy.

  It would be better if the hacks were fixed to manage 
  the i18n aspects that 
  tk has done in the past, but I don't understand them 
  well enough to do a 
  good job, nor have I figured out what Xft should do to 
  help solve the 
  problem.
  ----

  I'm attaching his patch, which was likely against 
  8.3.x so it doesn't get lost again.  It is a tgz with 
  two files that belong in tk/unix/.


tkt_uuid: 539309ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: None
resolution: Accepted
title: make dependence on msgcat "soft"
comment:
  Tk 8.4 adds localized widgets.  That's good.

  However, this means that Tk depends on the msgcat
  package.  In the unusual situation where msgcat
  is not installed, Tk refuses to load.  It would
  be better for Tk to load and fall back on using
  English messages.


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

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

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

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


tkt_uuid: 539903ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: None
title: Doc error for "-message"
comment:
  The option -message takes an argument, the message to 
  be set. This is not specified in the manpage.


tkt_uuid: 540013ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 71. Error Handling
priority: 5 Medium
foundin: None
resolution: Accepted
title: wm stackorder error message
comment:
  wm stackorder reports isabove|isbelow as optional
  but this is not true, the keyword has to be present.


  % toplevel .t
  .t
  % wm stackorder . isabove .t
  0
  % wm stackorder . isbelow .t
  1
  % wm stackorder . .t
  wrong # arguments: must be "wm stackorder
  window ?isabove|isbelow? ?window?"
  %


tkt_uuid: 540061ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: improve canvas line performance
comment:
  Back in 1993, Scott Schwartz <schwartz@bio.cse.psu.edu>
  posted to CLT a patch to hve better drawing
  performance of line segments on a canvas.  Idea
  is to make fewer X library calls and have each call
  do more.  See:

  http://groups.google.com/groups?q=group:comp.lang.tcl+author:Scott+author:Schwartz&hl=en&selm=CA4DwF.3uF%40cs.psu.edu&rnum=90

  There may be ideas in that patch worth exploiting.


tkt_uuid: 540238ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: -- New Stub Entries
priority: 5 Medium
foundin: None
resolution: Out of Date
title: TkWin*DrawableDC
comment:
  >From "Lothar Linhard" <lothar@concept.de>


  Make TkWinGetDrawableDC and TkWinReleaseDrawableDC
  available to extensions.


tkt_uuid: 540375ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 43. Photo Image|PPM
priority: 5 Medium
foundin: None
resolution: Fixed
title: ppm photo images: support -data option
comment:
  Error in startup script: -data option isn't supported
  for PPM images
      while executing
  "image create photo -format PPM -data $str"

  So, support it.


tkt_uuid: 540920ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 67. Unix Window Operations
priority: 3 Low
foundin: None
resolution: None
title: Access to 'container' id
comment:
  On my system, if I do
    exec xwininfo -tree -id [wm frame .]
  I get output something like this:

    xwininfo: Window id: 0x3810df9 (has no name)

      Root window id: 0x2a (the root window)
                           (has no name)
      Parent window id: 0x2a (the root window)
                             (has no name)
         10 children:
         0x3810e03 (has no name): ()
                                 200x200+5+24  +312+72
            1 child:
            0x5c00004 "wish8.3": ("wish8.3" "Wish8.3")
                                 200x200+0+0  +312+72
               1 child:
               0x5c00003 (has no name): ()
                                 200x200+0+0  +312+72
         [... rest of output elided ...]

  Now, the window id of the frame, 0x3810df9, is easily
  obtainable with [wm frame] and the window id of the
  drawing area is also easily obtainable with [winfo id],
  but the window id of the window that comes between them
  (present on UNIX/X because the window that implements
  the menubar for a window is a sibling of the toplevel
  drawing area, not a child of it, so an extra container
  is needed to hold them both) is not available without
  doing a hack (rummaging through the output of xwininfo
  or hacking around with XQueryTree.)  Wouldn't it be
  better if there was a way to expose this information at
  the Tcl and C levels in a cleaner way?  (You need it
  when you apply a non-rectangular shaping to a window,
  for example, because window managers only notice
  reshaping events on the container, not its children.)


tkt_uuid: 541256ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 8
foundin: obsolete: 8.4a5
resolution: Duplicate
title: segfault reading BMP image
comment:
  The bug may really be in the Img package.

  % package require Img
  1.2.4
  % image create photo -file oommf-small.bmp

  Program received signal SIGSEGV, Segmentation fault.
  0x20000441020 in Tcl_Read (chan=0x120159c20,
  dst=0x11fffe9c8 "", bytesToRead=6)
      at ./../generic/tclIO.c:4106
  4106        chanPtr = statePtr->topChanPtr;
  (gdb) bt
  #0  0x20000441020 in Tcl_Read (chan=0x120159c20,
  dst=0x11fffe9c8 "", 
      bytesToRead=6) at ./../generic/tclIO.c:4106
  #1  0x20000e33824 in ImgRead () from
  /usr/local/lib/Img1.2/libimg1.2.so
  #2  0x20000e3c1dc in ReadGIFHeader () from
  /usr/local/lib/Img1.2/libimg1.2.so
  #3  0x20000e3b030 in ChanMatchGIF () from
  /usr/local/lib/Img1.2/libimg1.2.so
  #4  0x20000239fe8 in MatchFileFormat
  (interp=0x120101910, chan=0x12016e360, 
      fileName=0x120159c20 "oommf-small.bmp",
  formatObj=0x0, 
      imageFormatPtr=0x11fffeb78, widthPtr=0x11fffeb80,
  heightPtr=0x11fffeb84, 
      oldformat=0x11fffeb90) at
  /local/src/tk/unix/../generic/tkImgPhoto.c:3577
  #5  0x20000235bd4 in ImgPhotoConfigureMaster
  (interp=0x120101910, 
      masterPtr=0x1201b8e40, objc=2, objv=0x1201030d8,
  flags=0)
      at /local/src/tk/unix/../generic/tkImgPhoto.c:1862
  #6  0x20000231998 in ImgPhotoCreate
  (interp=0x120101910, 
      name=0x11fffeca0 "image1", objc=2,
  objv=0x1201030d8, 
      typePtr=0x200003827f0, master=0x12016f3b0,
  clientDataPtr=0x12016f3b8)
      at /local/src/tk/unix/../generic/tkImgPhoto.c:532
  #7  0x20000227b78 in Tk_ImageObjCmd
  (clientData=0x120123d60, 
      interp=0x120101910, objc=2, objv=0x1201030d8)
      at /local/src/tk/unix/../generic/tkImage.c:300
  #8  0x200003d25e8 in TclEvalObjvInternal
  (interp=0x120101910, objc=5, 
      objv=0x1201030c0, command=0x0, length=0, flags=0)
      at ./../generic/tclBasic.c:3030
  #9  0x2000041b094 in TclExecuteByteCode
  (interp=0x120101910, 
      codePtr=0x12016f240) at
  ./../generic/tclExecute.c:1285
  #10 0x2000041a158 in TclCompEvalObj
  (interp=0x120101910, objPtr=0x120157b80)
      at ./../generic/tclExecute.c:931
  #11 0x200003d3e48 in Tcl_EvalObjEx (interp=0x120101910,
  objPtr=0x120157b80, 
      flags=131072) at ./../generic/tclBasic.c:3903
  #12 0x20000436b04 in Tcl_RecordAndEvalObj
  (interp=0x120101910, 
      cmdPtr=0x120157b80, flags=131072) at
  ./../generic/tclHistory.c:142
  #13 0x200004368b8 in Tcl_RecordAndEval
  (interp=0x120101910, 
      cmd=0x12010e1a8 "image create photo -file
  oommf-small.bmp\n", flags=131072)
      at ./../generic/tclHistory.c:62
  #14 0x20000189d8c in StdinProc (clientData=0x12015d270,
  mask=2)
      at /local/src/tk/unix/../generic/tkMain.c:355
  #15 0x2000044586c in Tcl_NotifyChannel
  (channel=0x12015d270, mask=2)
      at ./../generic/tclIO.c:6705
  #16 0x2000049c97c in FileHandlerEventProc
  (evPtr=0x1201bdfb0, flags=-3)
      at ./../unix/tclUnixNotfy.c:624
  #17 0x20000461d40 in Tcl_ServiceEvent (flags=-3)
      at ./../generic/tclNotify.c:607
  #18 0x20000462350 in Tcl_DoOneEvent (flags=-3) at
  ./../generic/tclNotify.c:910
  #19 0x20000174bb0 in Tk_MainLoop ()
      at /local/src/tk/unix/../generic/tkEvent.c:1290
  #20 0x20000189af0 in Tk_MainEx (argc=1,
  argv=0x11ffff588, 
      appInitProc=0x120000ae0 <Tcl_AppInit>,
  interp=0x120101910)
      at /local/src/tk/unix/../generic/tkMain.c:284
  #21 0x120000ab8 in main (argc=1, argv=0x11ffff588)
      at /local/src/tk/unix/tkAppInit.c:77


tkt_uuid: 541849ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 9 Immediate
foundin: obsolete: 8.4a4
resolution: Fixed
title: error with -overrelief & disabled widget
comment:
  If I create a widget with a -overrelief and an 
  initially disabled state, there is an error when the 
  mouse leaves the widget.

  The following reproduces the problem on my win2k box:

  button .b -text "Hello" -state disabled -overrelief 
  raised -relief flat
  pack .b

  run the above, and move the cursor over and then away 
  from the button. I get the following error:


  Error: can't read "Priv(relief)": no such element in 
  array

  Looking in button.tcl, the problem is in the procedure 
  tk::ButtonEnter or tk::ButtonLeave. Take your pick :-)

  Notice that in tk::ButtonEnter, Priv(relief) is only 
  set if the widget is *not* disabled. However, a 
  similar check for disabled-ness isn't made in 
  tk::ButtonLeave. 

  The bug has other cool side effects as well. 
  Ferinstance, run the following:


  button .b1 -state normal -overrelief sunken -relief 
  flat -text b1
  button .b2 -state disabled -overrelief raised -relief 
  groove -text b2
  pack .b1 .b2

  Move your mouse over b1 and then b2. Notice that when 
  you move the mouse away from b2 it gets the relief of 
  b1. This is because Priv(relief) is set when the mouse 
  enters b1, and isn't reset when the mouse leaves. When 
  the mouse enters b2, Priv(relief) is not set, so on 
  <Leave> the widget gets whatever relief was in play 
  for the last enabled button widget. 

  Bummer, huh?

  One fix might be simply to move all of the code in 
  ButtonLeave inside a check on the state. It seems to 
  work on my box for the above two test cases.

  proc ::tk::ButtonLeave w {
      variable ::tk::Priv
      if {[string compare [$w cget -state] "disabled"]} {
  $w configure -state normal

         # Restore the original button relief if the 
  mouse button is down
         # or there is an -overrelief value.

         if {[string equal $Priv(buttonWindow) $w] || \
                 [string compare [$w cget -
  overrelief] ""] } {
            $w configure -relief $Priv(relief)
         }
      }

      set Priv(window) ""
  }

  I've attached a patch that moves the code under the 
  test for disabledness. I also took the liberty of 
  converting those brain-numbing [string compare]'s with 
  the new "eq" and "ne" operators, and attempted to make 
  appropriate changes in the unix and mac 
  implementations, but have no way to test them. So 
  tread cautiously with the patch...


tkt_uuid: 541999ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: long lines with -wrap none. fixes
comment:
  Long lines (eg 10,000 characters) that are displayed 
  with -wrap none demonstrate a variety of bugs.

  Firstly display is slow (more noticable with really 
  long lines) and secondly the tag colours, 3d bevels, 
  and the text itself is often displayed incorrectly.

  The source of all of these bugs is 16-bit limitations 
  in the coordinates for X11. The patch adds in a 
  variety of add-hoc manual clipping in order to keep 
  coordinates within the 16-bit space.

  Note that the same bugs also occur on windows due to 
  the 16-bit code in the xlib translation layer (eg 
  XSegment, XPoint and XRectangle structure 
  definitions). 

  This patch was implemented and tested with 8.3.1, but 
  the fix has been added into files checked out from 
  cvs HEAD today (10th April 2002), although they have 
  not been tested with that version. (I doubt there'll 
  be any difference as the files changed have not had 
  may edits.)


tkt_uuid: 542199ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: None
title: entry widget: Dclick on character selection problem
comment:
  The bug was originally part of 220943. A number
  of problems were created by an earlier change.
  The problem described as (2) was not caused by the
  modification and so it has been extracted into
  this bug report. Test cases and the proposed
  patch have been added here.

  It is included here.

  (2) Double-click on the "c" in the first line, near its
  RIGHT edge. The "c" becomes selected, as it should.
  Now, double-click on the "c" near its LEFT edge,
  keeping the button down after the second click. The
  space to the left of the "c" is selected, not the "c"
  itself. Now, move the mouse by ONE PIXEL in any
  direction. The "ab" becomes selected as well.

  ...

  The behavior described in (1) and (2) is obviously
  incorrect. (In the case of clicking on the "c" near its
  left edge, you might argue that you are effectively
  clicking on the gap between the space and the "c" and
  that therefore it is not necessarily incorrect for the
  space to be the thing selected; but it certainly is
  counterintuitive, since one expects the letter clicked
  on to be part of the selected text.)


tkt_uuid: 544197ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: None
resolution: Later
title: Add NeXT-style scrollbars to Unix
comment:
  This patch adds a "-nextstyle" boolean attribute to the
  Unix scrollbar implementation.  NeXT-style scrollbars
  collect both arrow buttons at one end of the scrollbar.
   Both vertical and horizontal scrollbars are supported.

  In the patch, NeXT style scrollbars are enabled by
  default, search for "FIXME" to find this line.


tkt_uuid: 544565ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Invalid
title: Bug in grid or canvas...
comment:
  Hi all,

  My application started looking differently since around 15 Oct 2001,

  The affected item is a canvas widget that contains a tree whose nodes 
  are frames (windows) that contain 2 checkboxes and a label.
  This canvas is contained inside a frame along with 2 scrolbars,
  using the grid manager. The way the canvas is gridded is
  used countless times in the application and in all instances
  it behaves as expected, a scrollable canvas with automatic scrollbars.
  But in this specific window, it behaves strangely and very different
  from 8.4a4 downlaoded a couple of weeks ago.

  What I see is very strange. The layout is simple:
  A frame that contains a canvas and 2 scrollbars.
  Grig is used, with canvas at col 0 row 0, vertical scrollbar
  at row 0 col 1, hor. scrollbar at row 1 col 0. All use -sticky snew.

  What I see is two vertical strips of an unknown widget (!) at the
  two vertical sides of the canvas, of approx. width of 20 pixels.
  (A screenshot can be found at
  http://www.iit.demokritos.gr/~petasis/Tcl/GridCanvasBug84a4.gif )
  These two bars have the default colour of a newly created window,
  but they do not belong either to the canvas (which is configured to
  have a white background) or to the frame (they do not change colour
  if you change the frame colour, and the frame does change colour, as it is
  visible in the square between the two scrollbars...)

  But considering the clipping that happens to the embedded windows, they
  are not clipped over these vertical bars. This means possibly that these
  bars belong to the canvas widget. But setting the focus on it, only the
  white area gets hilighted (as is visible in the picture).
  During canvas creation, I don't use any -pad?/-ipad? options.
  Scrolling the horizontal canvas, only the white area is scrolled.
  The vertical bars do not move.
  Also, the same code runs as expected (i.e. canvas filling completely the
  area) in a cvs version a couple weeks ago. In the meantime, only
  an update to the grid command has occured, regaring -uniform option.
  This is the only thing that seems relevant.

  I have run out of ideas :-) What can be wrong?

  George

  See also 
  http://groups.google.com/groups?q=comp.lang.tcl+petasis+canvas+bug&hl=el&selm=3C622A1F.E0A
  272F2%40iit.demokritos.gr&rnum=8


tkt_uuid: 544655ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Breaking MacOS 9 menus
comment:
  This bug report is to supercede #482139 as it doesn't
  need BWidget anymore to show the bug and is a short
  plaint tcl file.

  Current implementations (Tcl/Tk 8.3.4) of menu drawing
  routines have some show-stopper errors contained. The
  short example script attached shows how to reproduce a
  strange error:
  changing the labeltext when having menus open breaks
  the menus, that is, the menus are then shown relative
  to the menu window and not to the normal Mac
  Topmenubar.

  How to reproduce the error on Mac OS 9 (perhaps 8 too):

  1. start the attached script, make the window
  sufficiently large to show the label and place the
  window, say, amidst the screen.
  2. choose the first menu entry (labeled 'now') -> the
  label will change immediately and correctly
  3. now choose the second menu entry (labeled
  'after2000'). This will trigger the label change after
  2 seconds. BEFORE it has triggered, re-open the menu
  and let it stay open (that is, do not choose a menu
  entry).
  4. Wait for the after2000 to trigger

  5. You will now see two things:
    - that the normal menu (hopefully still opened, if
  not, restart at point 2) does not respond anymore.
    - parts of the menu are now drawn relative to the
  wish application window (that is, amidts the screen
  now), go with the mouse there and those menue will
  work. This does even include the Mac system menus!

  I'm a kind of perplexed.

  We've seen this kind of error also during other
  operations that involved gridding operations when
  having menus open, though I'll fill in a separate bug
  report once I extracted a small test case there too.

  Regards,
           Bastien


tkt_uuid: 545159ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: canvas to photo
comment:
  I'de like to be able to dump the contents of a canvas to a 
  photo image, and then use the photo 'write' subcommand
  to save to disk, this would open up many animation type 
  applications in using TK, or maybe just add a 'write' 
  subcommand to the canvas?


tkt_uuid: 546333ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Fixed
title: message catalogs not namespaced
comment:
  The [mcset] command of the msgcat package uses
  its namespace context to keep message catalogs
  from different packages from conflicting with
  one another.  In order for this to work, the
  message catalogs provided by each package need
  to be evaluated in the namespace of that package.

  This means each file matching tk/library/msgs/*msg
  ought to have its contents enclosed in a

  namespace eval ::tk { ... }

  If desired, the catalogs could be broken down
  further according to the internal namespaces of
  Tk, but the simple step above is sufficient.


tkt_uuid: 546586ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: -- New Widgets
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: labelframe label options
comment:
  I would like to see the new labelframe widget take more
  of the label options. For instance:

  -textvariable
  -state
  -activebackground
  -activeforeground
  -disabledforeground
  -wraplength
  -anchor
  -image
  -compound

  If indeed the labelframe is a combination of the label
  and frame widgets, this would make sense to me.

  Of course, you can work around this, by creating a
  second label widget and using the -labelwidget option,
  but this seems clunky.


tkt_uuid: 546607ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: problem with cursor change
comment:
  I have a problem with cursor change using Tkogl (opengl extension) under Windows.
     Tkogl creates Tk_Window-window (A) and opengl-window (B) as a child of A.
     B is not Tk_Window. B just posts some messages to its parent (A) so I have no
     problem with bindings and with cursor change. But I can see the desired cursor (over B)
     only when I move the mouse or press the button. As soon as I stop moving or release the button 
  -   the cursor changes to IDC_ARROW.

      It happens because of "mouseTimer" that is created in Tk_PointerEvent(hwnd, x, y) 
  (tkWinPointer.c line 149).
      MouseTimerProc calls Tk_PointerEvent(NULL, pos.x, pos.y) (tkWinPointer.c line 239).

      Note that hwnd is NULL, so Tk_PointerEvent "must" find hwnd.

       hwnd = WindowFromPoint(pos); (tkWinPointer.c line 139).

      WindowFromPoint returns hwnd of B (rightly) which is not Tk_Window.
      When
   
       tkwin = Tk_HWNDToWindow(hwnd); (tkWinPointer.c line 141)

      so tkwin is NULL now.

      After this
       Tk_UpdatePointer(tkwin, pos.x, pos.y, state); (tkWinPointer.c line 145)
      with tkwin==NULL will change cursor to "None".
      
      I see two simple ways to avoid this problem - 
       1. Not to change cursor to "None" in UpdateCursor(winPtr) (TkPointer.c line 546) when 
  winPtr==NULL.
       2. Replace 
        tkwin = Tk_HWNDToWindow(hwnd); (tkWinPointer.c line 141)
       with
        tkwin = NULL;
        while (tkwin==NULL && hwnd!=NULL) {
         tkwin = Tk_HWNDToWindow(hwnd);
         hwnd = GetParent(hwnd);
        }


tkt_uuid: 546910ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 06. Canvas PostScript
priority: 8
foundin: None
resolution: Accepted
title: International postscript output
comment:
  This patch enables postscript output for characters
  that are neither in latin1 nor in system encoding. It's
  based on Victor Wagner's patch (encoding vector
  generation for unibyte system encoding). With my patch,
  characters that are not  in system encoding are
  displayed using "glyphshow". It also works fine when
  system encoding is multibyte (e.g. *_*.UTF-8 locales)


tkt_uuid: 547593ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Duplicate
title: Error creating Label > 32k pixels
comment:
  I believe there is a bug in Tk when creating a Label
  which is greater than 32k pixels.  See the bug report
  in python 'IDLE calltips cause application error', 

  http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470

  The code which generated the problem is in
  Tools/idle/CallTipWindow.py:30.  The code that looks
  relevant is:

  self.tipwindow = tw = Toplevel(self.widget)
  tw.wm_overrideredirect(1)
  label = Label(tw, text=text, justify=LEFT,
                background="#ffffe0", relief=SOLID,
                borderwidth=1, font=self.widget['font'])
  label.pack()

  The length of the text is about 3000 characters or 32k
  pixels.


tkt_uuid: 548726ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Fixed
title: resizing problems
comment:
  panedwindow .pw -orient v
  label .pw.l1 -text 12345
  label .pw.l2 -text ABCDE
  pack .pw -fill both -expand 1
  .pw add .pw.l1 -sticky nsew -minsize 1
  .pw add .pw.l2 -sticky nsew -minsize 1
   
  remember the configuration
   
  now resize "." to be bigger.
  now resze "." to be smaller (back to original size 
  roughly)
  things should look ok
   
  now resize "." to be bigger.
  drag the sash down and release
  drag the sash back up and release
  now resize "." to be smaller --- notice bottom pane 
  does not behave as it did before --- it does not 
  shrink.
   
  One way that kind of gets around it to add a another 
  sash
   
  frame .phantom
  .pw add .phantom
  bind .pw <Configure> {
    .pw sash place 1 0 30000
  }
   


tkt_uuid: 548765ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Radiobutton with -value "" drawn badly
comment:
  When creating a radiobutton with -value ""
  it is not drawn properly if the -variable
  was created by the radiobutton.

  pack [radiobutton .rb -variable Apa -value ""]

  The radiobutton is drawn unselected until the
  mouse passes over it.


tkt_uuid: 548791ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 48. Geometry Management
priority: 5 Medium
foundin: None
resolution: Fixed
title: Bug fix for GridReqProc
comment:
  /* 
  check for gridPtr!=NULL in "if"
  It can be NULL when tk is embedded.
  */

  static void
  GridReqProc(clientData, tkwin)
      ClientData clientData;/* Grid's information 
  about
   * window that got new 
  preferred
   * geometry.  */
      Tk_Window tkwin;/* Other Tk-related 
  information
   * about the window. */
  {
      register Gridder *gridPtr = (Gridder *) clientData;

      gridPtr = gridPtr->masterPtr;
      if (gridPtr && !(gridPtr->flags & 
  REQUESTED_RELAYOUT)) {
  gridPtr->flags |= REQUESTED_RELAYOUT;
  Tcl_DoWhenIdle(ArrangeGrid, (ClientData) 
  gridPtr);
      }
  }


tkt_uuid: 551969ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 31. Cursor Names
priority: 4
foundin: None
resolution: None
title: VFS and mouse cursor specification files
comment:
  Tcl version: 8.3.4
  OS Platform: Windows 2000

  Problem behaviour:
  The issue concerns the configuration of the mouse
  cursor through a separate mouse cursor specification
  file, e.g.

      . configure -cursor @linkcursor.cur

  When a script is run as a scripted document and the
  mouse cursor specification file is contained within the
  scripted document, the configuration command command
  fails, returning the error message:

  bad cursor spec
  "@F:/whateverpath/mousetest.sdk/bin/linkcursor.cur"

  (Both a script from which you can construct a scripted
  document that reproduces the error, and a scripted doc
  are packed in the attached zip file.)

  The faulty behaviour has been noticed when running
  under windows, however, I question whether it is
  platform specific.


  Expected nehaviour:
  The mouse cursor specification file should be read from
  the VFS and the shape of the mouse cursor should change
  accordingly.


  Jean Claude Wippler has tracked the problem down to:

  quote jcw start

  PS.  Oops, wait - I think I found the problem, it's 
  Windows-specific. The "win/tkWinCursor.c" has a call
  "LoadCursorFromFile", and I can't find
  LoadCursorFromFile anywhere else, so it looks like this
  call has not yet been made VFS aware. 

  quote jcw end


  Sincerely,

  Erik Leunissen
  ==============


tkt_uuid: 552366ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 7 High
foundin: obsolete: 8.4a4
resolution: Fixed
title: Priv(repeated) undefined in checkbutton
comment:
  When you click then release the mouse button on a
  checkbutton in OS X, you get an error reading:

  can't read "Priv(repeated)": no such variable
      while executing
  "if { $Priv(repeated) == 0 } {
          uplevel #0 [list $w invoke]
  }"
      (procedure tk::ButtonUp" line 18)
      invoked from within
  "tk::ButtonUp .editdlog/style.client.fr.fontchk"
      (command bound to event)

  I looked at the standard TCL library button.tcl file
  and noticed that for the Mac ::tk::ButtonDown
  procedure, the line:

      set Priv(repeated) 0

  was only inside the -repeatdelay check.  But in
  ::tk::ButtonUp, the check for Priv(repeated) was NOT
  inside a -repeatdelay check.  I moved the 'set
  Priv(repeated) 0' line to just before the after
  statement in ::tk::ButtonDown and everything started
  working correctly.


tkt_uuid: 552509ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: None
title: Patch 541999 and multi-byte strings
comment:
  The recent patch 541999 has some side effects
  that do not allow multi-byte strings to be drawn
  correctly by Tk_DrawChars. A patch is attached
  that tries to correct things while keeping
  the new things from the 541999 patch.


tkt_uuid: 552515ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Diff. bg color of canvas showing icons
comment:
  The icons in tk_messageBox are shown
  using a canvas. This canvas can have 
  different colour that the rest of the window,
  resulting in a strange appearence.
  Attached is a small patch that tries
  to fix this...


tkt_uuid: 553207ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Fixed
title: cd {$FOO$} fails
comment:
  If a directory name contains '$foo' or '[foo]', then 
  the console throws an error when trying to 'cd' into 
  such a directory.

  For example:

  cd {C:/$OEM$}

  gives "Can't read "OEM" no such variable" error.


tkt_uuid: 553208ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Fixed
title: TCLDIR needs backslashes
comment:
  If I do 'nmake winhelp' with 'TCLDIR=../../tcl8.4' 
  then a 'copy' syntax error is reported.  One has to 
  use backslashes (TCLDIR=..\..\tcl8.4).  No other make 
  operations seem to require backslashes, so it seems 
  this restriction ought to be removed.


tkt_uuid: 553212ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: None
resolution: None
title: Background images for widgets
comment:
  It'd be nice if all Tk widgets (or at least as many as
  possible) could support background images.  This was a
  feature that Barry Wegman <wegmanb@issi-hsv.com>
  mentioned (in email discussion) to me that he was
  looking for.  I don't know how well this ties in with
  native widgets...


tkt_uuid: 553283ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Fixed
title: Grab fails in tk_messageBox
comment:
  Under UNIX, if you try to launch two tk_messageBoxes,
  the second one replaces the first.  But when you click
  on the OK button, you get an application error.

  Try running this script under Unix:

    update
    after 1000 {
      tk_messageBox -icon error -type ok -message \
          "Click to get an error"
    }
    after idle {
      tk_messageBox -icon info -type ok -message \
          "Wait a second..."
    }


tkt_uuid: 553926ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: wm style stayontop, et al, patch
comment:
  I couldn't find this patch anywhere on the Tk SF site. 
  It may already
  be in someplace.  This patch provides a "wm style"
  command on Windows to give access to various extended
  Windows window attributes, such as "stay on top" and
  transparency.  The author, Jay Schmidgall, sent it to
  me some time ago with the following message:

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

  The next big style option under WinXX would probably be
  to add support for icons in the status area or system
  tray. However, there's much more to it than just a few
  options, e.g., you would need to be able to set up
  bindings and all that to handle button clicks, give it
  an icon to put in the tray, etc.

  The syntax is as follows:

      wm style window ?style? ?boolean?

    where ?style? is one of: 

      caption, dialog, maximize, minimize, stayontop,
  style,
      taskbar, transparent

    If ?boolean? is omitted, the current setting of
  ?style? is returned.

  Notes (or Bugs, if you prefer):

  When toggling the taskbar style, if the window is
  mapped, the window must first be withdrawn and then the
  style changed. Toggling the style without first
  withdrawing the window will have no effect on the
  window's presence in the taskbar, even if the window is
  later withdrawn and deiconified.

  Making multiple windows stayontop results in those
  windows being on top of all other windows, but
  maintaining a stacking order between themselves; there
  is no churn going on.

  Changing styles causes interactions in varying ways.
  For instance,
  setting either just the minimize or maximize style
  false simply
  disables that button. Setting them both, however,
  causes both buttons to be removed from the title bar.

  Removing a window from the task bar causes its minimize
  and maximize buttons to be removed, as well as its
  system menu, though the close box remains.

  Removing a windows's system menu causes removal of the
  minimize,
  maximize and close buttons.

  Removing the caption results in a window much like one
  with
  overrideredirect on, but the window remains resizable
  In addition,
  the space taken up by the caption becomes available to
  the window.

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


tkt_uuid: 554346ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.4a5
resolution: Out of Date
title: spaces in paths break stuff (with patch)
comment:
  Here's a companion patch to the one attached to
  Tcl Bug 553544.  Apply both and Tcl/Tk will
  properly configure/build/install even when there
  are spaces in the build or install paths.


tkt_uuid: 554763ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 4
foundin: TIP Implementation
resolution: Fixed
title: TIP #104 Reimplement undo stack + minor fixes
comment:
  This is a Tk 8.4a4 patch.

  The purpose is a reimplemtation of the undo stack.
  An item on the undo stack is now a list of items
  containing two scripts (Tc_Obj's): the apply action
  (for redo) and the revert action (for undo).
  This opens the path to undoing more than only text
  inserts and deletions, such as applying or removing
  tags (this is not part of the patch however).

  The undo stack implementation has been separated from
  the text widget, and is in fact usable by other
  widgets as well now.

  Some typos in the text.n doc are corrected as well,
  and a problem with the tk::TextPaste function (pasting
  twice) was also corrected.

  This patch has only been verfied on Red Hat Linux 7.2

  The Windows Makelfile.in was adapted to accomodate the
  new tkUndo.c and tkUndo.h files.

  The Mac section was NOT adapted yet for these two new
  files.


tkt_uuid: 555396ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: None
resolution: Duplicate
title: 8 bit character support broken
comment:
  Some time in the recent weeks, something changed in the
  CVS code that has severely broken 8 but character
  display. The symptoms I see occur using the text widget
  and Hipp's HTML widget. These are the symptoms:

  - When typing in the text widget, deadkey suuport no
  longer works. So when I press ^e, I get "^e" instead of
  ê. This works in 8.3

  - An accented character at the end of the word makes
  the whole word invisible. So some thing like

  La vérité naît de la bouche des enfants

  is displayed like this

  La        naît de la bouche des enfants.

  - If the accented character is at the end of the line,
  the whole line isn't displayed

  - I see the same thing with the HTML widget. Similarly,
  using the widget with 8.3 doesn't show these symptoms
  so I surmise that the problem is with Tk.


tkt_uuid: 556259ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Fixed
title: Tk_PhotoPutBlock() and alpha
comment:
  Tk_PhotoPutBlock() does not handle alpha very well.
  - First, it does a memcpy() where it should not (it
  should never).
  - Second, when copying into unassigned pixels (alpha of
    destination is 0), destination pixels are initialized
  with 0xd9.
    Why not just copy (not blend) the source ?

  Also, it would be nice to update comment that says
  "24 bits per pixel" and pix24 field of PhotoMaster
  struct.

  There is also an problem with [image put] command. With
  internal format, you can do:
    $image put #000000 -to 0 0 50 50
  to fill all these pixels, but you can't with a user
  defined format,
  since Tk_ImageStringReadProc receives width and height
  of its
  data bounded to the -to area.
  This can be solved by setting width and height to the
  -to area
  (line 1010-1015 of tkImgPhoto.c), but I don't know the
  side effect
  on existing format handler.


tkt_uuid: 556350ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: None
resolution: Fixed
title: Tk 8.4a5 core dump on Exit
comment:
  I am attaching a transcript of a core dump found in the
  Tk 8.4a5 from May 7, 2002 snapshot stored at
  activestate.com's ftp site.

  When running the following program:
  #!/bin/sh
  # the next line restarts using wish \
  exec /usr/tcl84/bin/wish "$0" "$@"

  package require Iwidgets

  button .exit_bt -text "Exit" -command "destroy ."

  iwidgets::combobox .combo -textfont {Helvetica -12 bold}

  pack .exit_bt

  and pressing the resulting button, I get a core dump.
  The stack trace included appears to be pointing to Tk
  from what I can tell.

  Tcl/Tk from CVS head
  Compiled with Sun's C compiler under SPARC Solaris 2.6.
  Running on CDE wm Solaris 8 Sun Blade.


tkt_uuid: 556526ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: Fixed
title: Text item displaced with negative coords
comment:
  When placing a text item on a negative coordinate
  it is displaced one pixel. I.e a text at -1 is
  placed at the same place as one at 0.

  Example:

  pack [canvas .c -width 40 -height 40]
  foreach x {-2 -1 0 1 2} \
          col {white green black red blue} {
      .c create text $x $x -text 5 \
          -font "Courier 20" -fill $col
  }
  .c configure -scrollregion [.c bbox all]
  It can be seen that the white (at -2) is next
  to the black (at 0), and the green (at -1) is
  not seen at all (covered by the black).
  The bug is in tkCanvText.c row 638,
  function ComputeTextBbox:
      leftX = (int) (textPtr->x + 0.5);
      topY = (int) (textPtr->y + 0.5);

  That rounding does not work well with negative
  numbers which causes the effect.
  They should use proper rounding that works on both
  positive and negative numbers, e.g.:

      leftX = (int) floor(textPtr->x + 0.5);
      topY = (int) floor(textPtr->y + 0.5);


tkt_uuid: 557083ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Adding Tk_PhotoBlendBlock()
comment:
  Tk_PhotoPutBlock() blends the source block with the
  image, which prevent extension writer to set alpha
  value in the image.

  So it would be good to add Tk_PhotoBlendBlock() (and
  Tk_PhotoBlendZoomedBlock()) and make Tk_PhotoPutBlock()
  doing a solid copy of the source block.
  Also, [$image copy] and [$image put] can take an
  additionnal
  option, -blend /boolean/, to switch on
  Tk_PhotoPutBlock() or
  Tk_PhotoBlendBlock().


tkt_uuid: 557090ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 41. Photo Images
priority: 6
foundin: None
resolution: None
title: Allow alpha value in [image put]
comment:
  Default format handler doesn't deal with alpha value.
  I am writing a format handler, "pixel", where user can
  specify
  the following options:
    -colormodel hsv|rgb
       Color model to use for color cells 
    -packed /boolean/
       Specifies the format of each color cells. If
  false, a color
       cell is a list of 3 (or 4) values, between 0 and
  255,
       specifying the red, green, blue (and alpha)
  values,
       or hue, saturation, value (and alpha) values.
       if true, a color cell is a single integer, i,
  where
       (i >> 24) & 0xff is the alpha value,
       (i >> 16) & 0xff is the red or hue value,
       (i >>  8) & 0xff is the green or saturation value,
       (i        ) & 0xff is the blue or value
  (brightness) value.
    -alpha /boolean/
       Specifies wheter or not to use the alpha value
  when
       copying the data. If true, each color cell must
  have
       4 values. If false, each color cell must have 3 or
  4 values,
       and alpha value is set to 255.
       (another option could specify the alpha value to
  use for all pixels instead of 255).

  This new format handler allow among other things to
  specify
  alpha value at the tcl level.
  Perhaps we could also allow alpha specification in the
  default
  format handler, with a syntax like #rrggbb@aa.


tkt_uuid: 559078ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Fixed
title: Spinbox: -from overwrites -textvariable
comment:
  When I create a spinbox-widget with both options (from 
  and textvariable) like this:
  set t 8
  spinbox .sb -from 1 -to 16 -textvariable t
  Than spinbox shows "1" and sets t to 1.
  I would have expected that the option "textvariable" has 
  precedence over option "from".

  A workaround is:
  spinbox .sb -textvariable 5
  .sb configure -from 1 -to 16
  which works as expected.


tkt_uuid: 559435ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: None
title: tkUnixFont.c:Tk_DrawChars i18n problem
comment:
  As of 23 May 2002 cvs head, there is a problem with
  non-latin1 characters in Tk_DrawChars (unix). If the
  last character in the string is non-latin1, the entire
  last segment of line (having the same subfont) is not
  displayed at all. If I correct Tk_DrawChars assumption
  of 1byte=1char, I get the following: last character is
  displayed as "?" if it needs different subfont than
  previous character. Patch solving _both_ problems is 
  attached to this report.


tkt_uuid: 559437ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 64. Graphic Contexts
priority: 5 Medium
foundin: None
resolution: None
title: Fix for Bug 559435
comment:
  TkUnixFont.c: Tk_DrawChars doesn't handle non-ascii
  characters properly (esp. in the end of line). AFAIK,
  with this patch the problem is gone.


tkt_uuid: 559450ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Fixed
title: bind tag to [exit]: no cleanup
comment:
  The DestroyText() cleanup routine will only be
  called when all Tcl_Preserve() calls on the
  textPtr are matched with Tcl_Release() calls.
  This is to protect against freeing textPtr
  when callers still need it.

  However, this also prevents DestroyText from
  cleaning up other resources held by the text
  widget, notably fonts.  When fonts are not
  properly cleaned up, Tk aborts on [exit] with
  a message noting that failure (Why?  Is this
  debugging code that escaped?)

  The attached demo script illustrates the problem.
  Any time a binding on a tag in the text is
  triggered, there is a Tcl_Preserve() active
  on the text widget, preventing clean up. If that
  binding happens to be [exit], (or if that binding
  starts a nested event loop, in which there's an
  [exit], etc....), then there's a panic().

  Other widgets handle this by keeping a "deleted"
  flag in the widget structure, and setting it
  when the structure is no longer valid because
  the widget has been deleted.  This separates the
  release of other resources like fonts -- part of
  deletion -- from the free()-ing of the struct
  itself.  Only the latter needs to be guaranteed
  by Tcl_Preserve, with checking of the "deleted"
  flag value serving as any other protection needed.

  Are there any compatibility problems expected with
  adding another field to the TkText struct?


tkt_uuid: 559792ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: None
title: Long line problem in canvas?
comment:
    The code below appears (I think) to illustrate a problem
  with long lines in a canvas. The code should (I think) produce 6
  lines of increasing length. The first 4 are OK, the last 2
  (the longest) appear to be drawn incorrectly and have some
  "odd" behaviour as you scroll (i.e. they appear at some point
  as you scroll down).

    Am I missing something?

  ---- Code ----
  set w .f
  frame $w

  canvas $w.bt -width 150 -height 400 \
  -scrollregion "0 0 150 60000" -yscrollcommand "$w.sb set"
  scrollbar $w.sb -orient vertical -command "$w.bt yview"
  pack $w.bt -side left -fill both -expand 1 -padx 5 -pady 5
  pack $w.sb -side left -fill y

  pack $w -fill both -expand yes

  set off 10
  for { set c 1000 } { $c < 60000 } { incr c 10000; incr off 10 } {
  puts "create line $off 20 $off $c"
  $w.bt create line $off 20 $off $c
  }


tkt_uuid: 560679ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 6
foundin: None
resolution: Fixed
title: Missing -container crashes wish
comment:
  Embedding in a toplevel that has not set -container causes
  a crash. (At least on Win98, where I have seen it.)

  Script:

  toplevel .real 
  toplevel .embd -use [winfo id .real]

  Stack trace:

  Tk_GeometryRequest(Tk_Window_ * 0x00000000, int 0x000000c8,
    int 0x000000c8) line 154 + 6 bytes
  EmbedGeometryRequest(Container * 0x00beed00, int
  0x000000c8,
    int 0x000000c8) line 444 + 17 bytes
  TkWinEmbeddedEventProc(HWND__ * 0x00000498, unsigned
  int 0x00000401,
    unsigned int 0x000000c8, long 0x000000c8) line 400 +
  17 bytes
  TkWinChildProc(HWND__ * 0x00000498, unsigned int
  0x00000401,
    unsigned int 0x000000c8, long 0x000000c8) line 650 +
  21 bytes
  TopLevelEventProc(int * 0x00beef00, _XEvent *
  0x00bee988) line 3601


  The crash happens because Tk_GeometryRequest is called
  with a
  NULL pointer by EmbedGeometryRequest.
  My guess is that EmbedGeometryRequest should check if
  containerPtr->parentPtr is NULL.


tkt_uuid: 561452ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 26. Conversions from String
priority: 5 Medium
foundin: None
resolution: Fixed
title: encoding problems with Mac OSX
comment:
  The system encoding is not set correctly (cause the
  path to the encodings is not expanded) and the internal
  encoding is not converted when making buttons.

  setting of the right system encoding is a tcl patch but
  belongs to the other ones.

  When debugging with Project Builder the console works
  in utf-8 but the system encoding (for making buttons)
  is still macRoman.  When working from the Terminal the
  encoding can be choosen by the user but normally is
  macRoman (or for the unix guys iso8859-1).  The
  encoding of the tcl-console is macRoman.  So when
  testing, one needs to change the encoding for the input
  channel, if it is not macRoman (cause macRoman is the
  system encoding!)
    fconfigure stdin encoding utf-8

  The internal strings have to be converted if a native
  widget (called control by apple) is used.

  The attached patches are against the repository and the
  branch macosx-8-4-branch.


tkt_uuid: 561647ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: Adding more wm tests
comment:
  This patch adds some more test cases to wm.test.
  The tests are mainly simple script interface tests for
  all options, with argument checking and setting and
  reading values.

  This is intendend to provide a better starting point
  for objectifying wm. It feels better to have a better
  test suite before poking around too much.

  The patch includes some minor fixes correcting some
  error messages in the win, unix and mac wm files.

  This has only been tested on Win98, so some feedback
  from unix/mac would be appreciated.


tkt_uuid: 561708ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: None
resolution: Accepted
title: Make transient state mirror master state
comment:
  Here is a patch that changes the way transient windows
  and master windows work. The current implementation
  supports iconify of the transient when the master is
  iconified, but this does not work if you withdraw
  the master. Here is a quick example.

  toplevel .s ; toplevel .m
  wm transient .s .m

  If I run [wm iconify .m] at this point, both windows
  vanish from the display. If I were to instead run
  [wm withdraw .m] only the master window would be
  unmapped. The exact state that the transient is in
  at this point differs under Win32 and X. One might
  expect [wm deiconify .m] to work the same for a
  withdrawn master and an iconified master, but that
  too is broken.

  I have written up a bunch of test cases that deal
  with all of these state changes and the results
  under Win32 and X match exactly after my patch
  is applied. The patch also fixes a number of bugs
  in the current Win32 and X implementations of the
  wm transient command. I would feel much better about
  this change if someone could take a look at it to
  see if anything jumps out at them. I have run the
  full test suite under X and Win32 and the patch
  does not cause any failures.


tkt_uuid: 563140ffffffffffffffffffffffffffffffffff
type: Patch
status: Deleted
subsystem: 33. Generic Dialog Support
priority: 5 Medium
foundin: None
resolution: None
title: Smart behavior with translated labels...
comment:
  When labels of tk standard dialogs and message boxes
  are translated via msgcat, shortcut bindings and
  underline positions are still bound to english labels,
  which may me sometimes inconvenient or even harmful.
  This patch fixes this problem, introducing new approach
  to shortcut keys selection (no more need to specify
  '-underline' and bind <Alt-somekey> by hand). This is
  described in details at http://mini.net/tcl/3426.html


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

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

  I have duplicated this on both 8.3.2 and 8.4a5.

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

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

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


tkt_uuid: 564146ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: None
resolution: Works For Me
title: Russian translation file
comment:
  This file contains russian translation for Tk messages.
  However, inclusion of this file is DANGEROUS while
  patch #563140 is not applied - this will make tk less
  usable for russian users. This may be true for other
  translation files as well - without #563140, binding
  accelerator keys in msgbox.tcl triggers error for any
  button having label with the first char being non-ascii.


tkt_uuid: 564521ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: None
resolution: Accepted
title: Objectify wm
comment:
  This patch is for objectifying wm.

  The first patch attached only objectifies the Windows
  file, tkWinWm.c, to get feedback before starting on
  the Unix/Mac files.

  The patch has one function for each subcommand and
  hopefully many of those can be identical between
  platforms, which will simplify centralization of
  common code in a later step.


tkt_uuid: 564575ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 79. L10N
priority: 3 Low
foundin: obsolete: 8.4b2
resolution: Fixed
title: Tk [console]/demos should be localized.
comment:
  Running wish8.4a4 from ActiveTcl 8.4.0.1 Beta 2 under 
  Win2k generates a funny language mix: the titles in the 
  menu are in english, whereas the commands
  are in german.

  E.g. in wish itself the many looks like this: 
  File: Ausführen..., Konsole unsichtbar machen, Clear 
  Console, Ende
  Edit: Ausschneiden, Kopieren, Einfügen, Löschen
  Help: Über...

  Running default applications in ActiveTcl generates funny 
  effects like this: 
  Running tkv.tcl from Demos/Img generates a window 
  called "Viewer" with english menus and english commands, 
  but running the same from lib/Img1.2 gives a window 
  called "Betrachter" and everything in the menus is in 
  german.

  My system language is set to english (US) and virtually all 
  software is in english. There are a few programs in german 
  and a few, which should be in english but bother me with 
  german nevertheless, one of them now being
  wish ;-)
  There is one indication of german in my system, and that's 
  the keyboard, which is a swiss-german keyboard. But that's 
  all.


tkt_uuid: 564642ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: TIP Implementation
resolution: Fixed
title: TIP #84: mouse motion filtering patch
comment:
  Attached is an implementation of TIP #84 to add a hook 
  that avoids the current mouse motion filtering.


tkt_uuid: 564897ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: application doesn't activate
comment:
  If yours is an embedded application, clicking a widget in 
  a Tk window may not activate your application.  It will fail 
  to activate it if your main window is a Windows window.  

  Following is some code from the WmProc function in 
  the tkWinWm.c file that I found solves the problem.  

  case WM_MOUSEACTIVATE: {
      ActivateEvent *eventPtr;
      winPtr = GetTopLevel((HWND) wParam);

      /*
       * If you have Tcl embedded in a C 
  application, 
       * your Windows windows may be above 
  your Tcl windows 
       * in the window hierarchy.  In this case, 
  the message 
       * goes to the main application window.  
  Since the application 
       * window is above all the Tk windows, and 
  isn't a Tk window itself, 
       * when we try to "get its toplevel" we get 
  a null pointer. 
       *      The result is that the applicate 
  doesn't activate 
       * if we click a widget in the application.  
  The !winPtr || portion 
       * ensures that the message is passed 
  through and 
       * the application activates. 
       */
      if (!winPtr || winPtr && (TkGrabState
  (winPtr) != TK_GRAB_EXCLUDED)) {
  /*
   * This allows us to pass the 
  message onto the
   * native menus [Bug: 2272]
   */
  result = DefWindowProc(hwnd, 
  message, wParam, lParam);
  goto done;
      }


  I hope that correct operation of Tk in an embedded 
  context is a priority for the Tcl community.  


                                           Regards, 

                                           Rick


tkt_uuid: 565485ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 8
foundin: obsolete: 8.4a5
resolution: Fixed
title: Bad button sizing on Windows.
comment:
  I would expect that a button with -width and -height set
  has a size that is unaffected by its text. This is
  currently not true on Windows where an empty text gives
  a slightly smaller button.

  Also, I think a button with a one-line text should have
  the same size when -height is 0 and when it's 1.

  The attached patch fixes this and adds a test case
  in button.test since I think this behaviour should be
  platform independent. I have not tested on any other
  platform.

  Example: none of the buttons should change size:

  button .a -text Hej -font "Arial 12" -command exit
  button .b -text Hej -width 10 -height 1 -command exit
  wm geometry . 150x100
  place .a -x 10 -y 10
  place .b -x 10 -rely 0.5 

  proc apa {{odd 1}} {
      .a configure -height $odd
      .b configure -text [expr {$odd ? "" : "Hej"}]
      after 500 apa [expr !$odd]
  }
  apa


tkt_uuid: 565760ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Out of Date
title: tk compilation on macosx
comment:
  Hi all,

  I downloaded Tcl/Tk 8.3.4 source code and tried to
  compile on MacOSX.
  The Tcl compilation was ok but not for Tk.

  configure command:
  ./configure --prefix=/Users/raphael/software
  --x-includes=/usr/X11R6/include
  --x-libraries=/usr/X11R6/lib

  during make, Tk compilation failed at the Tk shared lib
  generation (libtk8.3.dylib).

  The commands produced by the Makefile was:

  cc -dynamiclib -prebind  -o libtk8.3.dylib tk3d.o
  tkArgv.o tkAtom.o tkBind.o tkBitmap.o tkClipboard.o
  tkCmds.o tkColor.o tkConfig.o tkConsole.o tkCursor.o
  tkError.o tkEvent.o tkFocus.o tkFont.o tkGet.o tkGC.o
  tkGeometry.o tkGrab.o tkGrid.o tkMain.o tkObj.o
  tkOldConfig.o tkOption.o tkPack.o tkPlace.o tkSelect.o
  tkUtil.o tkVisual.o tkWindow.o tkUnix.o tkUnix3d.o
  tkUnixButton.o tkUnixColor.o tkUnixConfig.o
  tkUnixCursor.o tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o
  tkUnixFocus.o tkUnixFont.o tkUnixInit.o tkUnixKey.o
  tkUnixMenu.o tkUnixMenubu.o tkUnixScale.o
  tkUnixScrlbr.o tkUnixSelect.o tkUnixSend.o tkUnixWm.o
  tkUnixXId.o tkStubInit.o tkStubLib.o tkButton.o
  tkEntry.o tkFrame.o tkListbox.o tkMenu.o tkMenubutton.o
  tkMenuDraw.o tkMessage.o tkScale.o tkScrollbar.o
  tkCanvas.o tkCanvArc.o tkCanvBmap.o tkCanvImg.o
  tkCanvLine.o tkCanvPoly.o tkCanvPs.o tkCanvText.o
  tkCanvUtil.o tkCanvWind.o tkRectOval.o tkTrig.o
  tkImage.o tkImgBmap.o tkImgGIF.o tkImgPPM.o
  tkImgPhoto.o tkText.o tkTextBTree.o tkTextDisp.o
  tkTextImage.o tkTextIndex.o tkTextMark.o tkTextTag.o
  tkTextWind.o  -L/Users/raphael/tcl8.3.4/unix

  I found several problems and solved them as follow:

  1) Missing paths for linking.
  with error message:

  ld: Undefined symbols:
  _Tcl_DeleteHashEntry
  _Tcl_Free
  ..

  That was easily solved by adding at the end of the cc
  command:
  -L/Users/raphael/tcl8.3.4/unix -ltcl8.3
  -L/usr/X11R6/lib -L/sw/lib -lX11 -ldl -lm -lc

  I guess that during the configure script generation or
  execution, the -L and linked libs need to be added in
  the Makefile (usually on other platforms, something
  like -L../../tclx.y/unix is added for tcl shared lib).

  2) With the corrected cc command, I got another error:

  ld: warning multiple definitions of symbol _dataKey
  tkMain.o definition of _dataKey in section
  (__DATA,__common)
  /Users/raphael/tcl8.3.4/unix/libtcl8.3.dylib(tclMain.o)
  definition of _dataKey

  It seems that this is related to the declaration of:

  Tcl_ThreadDataKey dataKey;

  in generic/tkMain.c
  By changing the declaration to:

  static Tcl_ThreadDataKey dataKey;

  the compilation goes ok.
  After that, I restarted make and managed to compile all.

  Thanks for this release since it solves the dynamic
  loading problem of the Tk shared lib through a tclsh
  script (command 'package require Tk') that was failing
  in earlier versions on MacOSX.

  Cheers,

  Raphael


tkt_uuid: 566605ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: None
resolution: Fixed
title: Underline position in translated labels.
comment:
  This patch is an alternative to #563140 that I consider
  more suitable. With this patch, texts for all labels
  and buttons in standard dialogs are specified in the
  form like "File &name:", then translated via msgcat.
  Underline is specified by ampersand position. 


tkt_uuid: 568253ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: None
resolution: Accepted
title: Patch to cleanup wm transient use in Tk
comment:
  This patch copies the wm transient checks that
  appear in some of the Tk dialogs into the others.
  There is a small functional change, if the parent
  window is withdrawn, then no transient master
  is set. All the tk dialogs should behave the same
  way after this patch is applied.


tkt_uuid: 568278ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: None
resolution: Accepted
title: Break tk dialog transient/master
comment:
  This patch fixes a problem where Tk dialogs can
  be mapped because a transient master (the -parent)
  is iconified/deiconified. This was a result of
  the new transient state mirroring functionality.


tkt_uuid: 568578ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Invalid
title: textIndex-5.2 kills xfs on Linux/Alpha
comment:
  Don't know what recent changes have been made here,
  but the test textIndex-5.2 pretty reliably does bad things
  to my XFree86-3.3.6-20 on Red Hat Linux 6.2 on Alpha.

  During a full `make test` it just hangs on that test with X
  consuming all CPU.  (AARRRRGGGHHH. just re-ran to
  verify, and no hang, so this isn't 100% repeatable.)

  If I limit the testing to the textIndex.test file (with
  -file option
  in TESTFLAGS) then the test just take uncomfortably long
  (a few seconds, while all others zip by in fractions of
  a second)
  and then sometimes (unreliably) I later have trouble with X
  closing and restarting when I log out/into another session.

  This is the first time I've noticed this trouble, have
  there been
  changes in this area recently?


tkt_uuid: 568701ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 7 High
foundin: obsolete: 8.4a5
resolution: Fixed
title: remove panic on unfreed fonts
comment:
  Line 439 of Revision 1.13 of generic/tkFont.c is a
  panic() when the font subsystem is finalizing, yet
  there are unfreed fonts.

  Unfortunately, we know that some Tk widgets, notably
  [text] and [canvas], do not always free the fonts they
  are using.  This panic() has been helpful in uncovering
  those bugs, but it is not a good thing to expose to
  end users.  We should either remove it, or perhaps
  disable it unless a debugging version of Tk is compiled.

  See also Tk Bugs 559450 and 458309.


tkt_uuid: 568861ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: None
resolution: Accepted
title: Fix for wm minsize and maxsize commands
comment:
  This patch is fixes problems with the wm minsize
  and wm maxsize commands. The basic problem is
  that one can use wm geom to set sizes that should
  not be allowed. There was also a bug where
  the window would not be resized when the minsize
  or maxsize was changed and a resize was required.

  I have added a number of test cases to the wm.test
  file. I have also removed tests from the unixWm.test
  file that were marked with the nonPortable constraint.
  These tests would fail, they were not being run
  by default, and in addition my tests are more complete.
  My tests also cover gridded windows.

  I see two possible arguments against my patch. First,
  that there is a conflict between the docs for minsize
  and maxsize and the implementation. The docs state
  that these method should be a no-op when the wm
  resizable command has been used to turn off the
  resizable prop. Thing is, the resizable docs
  only mention what the user can do interactively.
  My patch will make the window resize to the new
  min or max size and then not allow resizing after
  that. In addition, this is violated by the wm geom
  command which can resize a window even if the
  wm resizable prop is turned off.

  The other argument against the test cases is that
  they might not work on other window managers. For
  example, I had to take care to use windows that
  would not be too small under Win32, since it has
  a lower limit for window widths. It is possible
  that tests might fail under some window managers.
  Those problems will have to be dealt with as they
  come up. The benefit of actually testing the wm
  code across multiple platforms should outweigh
  the cost of touching up the tests so they work
  for some specific (meaning buggy) wm.


tkt_uuid: 569952ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 24. Relief
priority: 5 Medium
foundin: TIP Implementation
resolution: Fixed
title: Implementation of TIP #82
comment:
  The attached diff is the initial implementation
  of TIP #82.  This bug is submitted for tracking
  purposes only and will be closed as soon as the
  changes are committed.


tkt_uuid: 570306ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Fixed
title: tktest finalize segfault
comment:
  After running the clipboard.test file in the test
  suite, tktest
  has a segfault while finalizing.  The really weird thing is
  that the segfault shows up only when using a short glob
  pattern to select the file.  See below.

  (gdb) run ./../tests/all.tcl -file cli\*.test
  Starting program: /local/src/tk/unix/./tktest
  ./../tests/all.tcl -file cli\*.tes
  t
  Tk 8.4a5 tests running in interp: 
  /local/src/tk/unix/./tktest
  Tests running in working dir:  /local/src/tk/unix
  Sourcing files that match:  /local/src/tk/tests/cli*.test
  Tests began at Mon Jun 17 21:54:26 EDT 2002
  clipboard.test

  Tests ended at Mon Jun 17 21:54:29 EDT 2002
  all.tcl:        Total   35      Passed  35      Skipped
  0       Failed  0
  Sourced 1 Test Files.

  Program received signal SIGSEGV, Segmentation fault.
  0x200005c17a8 in chunk_free (ar_ptr=0x20000770de0,
  p=0x1203e67a0)
      at malloc.c:3121
  3121    malloc.c: No such file or directory.
  (gdb) bt
  #0  0x200005c17a8 in chunk_free (ar_ptr=0x20000770de0,
  p=0x1203e67a0)
      at malloc.c:3121
  #1  0x200005c4574 in __libc_free (mem=0x20000770de0) at
  malloc.c:3023
  #2  0x12020a1a8 in TclpFree (cp=0x1203e69f0 "") at
  ./../generic/tclAlloc.c:702
  #3  0x120135f68 in Tcl_Free (ptr=0x1203e69f0 "")
      at ./../generic/tclCkalloc.c:1160
  #4  0x12018c020 in Tcl_DeleteHashTable
  (tablePtr=0x12036fa48)
      at ./../generic/tclHash.c:618
  #5  0x12004b3ac in FreeUidThreadExitProc (clientData=0x0)
      at /local/src/tk/unix/../generic/tkGet.c:508
  #6  0x120172740 in Tcl_FinalizeThread () at
  ./../generic/tclEvent.c:906
  #7  0x120172520 in Tcl_Finalize () at
  ./../generic/tclEvent.c:804
  #8  0x120172108 in Tcl_Exit (status=0) at
  ./../generic/tclEvent.c:564
  #9  0x120137d88 in Tcl_ExitObjCmd (dummy=0x0,
  interp=0x120360480, objc=1,
      objv=0x120361c40) at ./../generic/tclCmdAH.c:667
  #10 0x12012dd90 in TclEvalObjvInternal
  (interp=0x120360480, objc=1,
      objv=0x120361c40, command=0x0, length=0, flags=0)
      at ./../generic/tclBasic.c:3012
  #11 0x120174ac8 in TclExecuteByteCode
  (interp=0x120360480, codePtr=0x1204800f0)
      at ./../generic/tclExecute.c:1279
  #12 0x120173bf8 in TclCompEvalObj (interp=0x120360480,
  objPtr=0x1204630d0)
      at ./../generic/tclExecute.c:917
  #13 0x12012f6c8 in Tcl_EvalObjEx (interp=0x120360480,
  objPtr=0x1204630d0,
      flags=0) at ./../generic/tclBasic.c:3907
  #14 0x1201c8c64 in TclObjInterpProc
  (clientData=0x12046cb70,
      interp=0x120360480, objc=2, objv=0x11fffeee0)
      at ./../generic/tclProc.c:1074
  #15 0x12012dd90 in TclEvalObjvInternal
  (interp=0x120360480, objc=2,
      objv=0x11fffeee0,
      command=0x12044988a "::tcltest::cleanupTests
  1\nreturn\n", length=26,
      flags=0) at ./../generic/tclBasic.c:3012
  #16 0x12012ee5c in Tcl_EvalEx (interp=0x120360480,
      script=0x120448ff0 "# all.tcl --\n#\n# This file
  contains a top-level script
   to run all of the Tk\n# tests.  Execute it by invoking
  \"source all.tcl\" when
  running tktest\n# in this directory.\n#\n# Copyright
  (c) 1998-1999 by Sc"...,
      numBytes=2235, flags=0) at ./../generic/tclBasic.c:3607
  #17 0x1201a6008 in Tcl_FSEvalFile (interp=0x120360480,
  pathPtr=0x1203ce740)
      at ./../generic/tclIOUtil.c:1355
  #18 0x1201a4c88 in Tcl_EvalFile (interp=0x120360480,
      fileName=0x11ffff248 "./../tests/all.tcl") at
  ./../generic/tclIOUtil.c:234
  #19 0x12004fe88 in Tk_MainEx (argc=3, argv=0x11ffff3b0,
      appInitProc=0x12002a500 <Tcl_AppInit>,
  interp=0x120360480)
      at /local/src/tk/unix/../generic/tkMain.c:234
  #20 0x12002a4d8 in main (argc=4, argv=0x11ffff3a8)
      at /local/src/tk/unix/tkAppInit.c:69

  Notice that "-file cli\*.test" was used.  Any longer
  prefixes from
  "-file clip\*.test" up to "-file clipboard.test" show
  no segfault.
  Shorter prefixes do show the segfault, but also cause more
  files to be tested.

  This problem is seen on the Linux/Alpha platform.


tkt_uuid: 570320ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Duplicate
title: tktest finalize segfault
comment:
  tktest has a segfault during finalization (display
  close) after
  running the tests in unixSelect.test on Linux/Alpha:

  (gdb) run ./../tests/all.tcl -file unixSelect.test
  Starting program: /local/src/tk/unix/./tktest
  ./../tests/all.tcl -file unixSelec
  t.test
  Tk 8.4a5 tests running in interp: 
  /local/src/tk/unix/./tktest
  Tests running in working dir:  /local/src/tk/unix
  Sourcing files that match: 
  /local/src/tk/tests/unixSelect.test
  Tests began at Mon Jun 17 23:13:10 EDT 2002
  unixSelect.test

  Tests ended at Mon Jun 17 23:13:52 EDT 2002
  all.tcl:        Total   9       Passed  9       Skipped
  0       Failed  0
  Sourced 1 Test Files.

  Program received signal SIGSEGV, Segmentation fault.
  0x200005c17a8 in chunk_free (ar_ptr=0x20000770de0,
  p=0x1204691e0)
      at malloc.c:3121
  3121    malloc.c: No such file or directory.
  (gdb) bt
  #0  0x200005c17a8 in chunk_free (ar_ptr=0x20000770de0,
  p=0x1204691e0)
      at malloc.c:3121
  #1  0x200005c4574 in __libc_free (mem=0x20000770de0) at
  malloc.c:3023
  #2  0x20000159e0c in _XFreeAtomTable () from
  /usr/X11R6/lib/libX11.so.6
  #3  0x2000015fbf8 in _XFreeDisplayStructure () from
  /usr/X11R6/lib/libX11.so.6
  #4  0x200001485ac in XCloseDisplay () from
  /usr/X11R6/lib/libX11.so.6
  #5  0x12005ebe0 in TkpCloseDisplay (dispPtr=0x1203762c0)
      at /local/src/tk/unix/tkUnixEvent.c:189
  #6  0x1200562d4 in TkCloseDisplay (dispPtr=0x1203762c0)
      at /local/src/tk/unix/../generic/tkWindow.c:263
  #7  0x120059cc8 in DeleteWindowsExitProc (clientData=0x0)
      at /local/src/tk/unix/../generic/tkWindow.c:2661
  #8  0x1201724e4 in Tcl_Finalize () at
  ./../generic/tclEvent.c:790
  #9  0x120172108 in Tcl_Exit (status=0) at
  ./../generic/tclEvent.c:564
  #10 0x120137d88 in Tcl_ExitObjCmd (dummy=0x0,
  interp=0x120360480, objc=1,
      objv=0x120361c40) at ./../generic/tclCmdAH.c:667
  #11 0x12012dd90 in TclEvalObjvInternal
  (interp=0x120360480, objc=1,
      objv=0x120361c40, command=0x0, length=0, flags=0)
      at ./../generic/tclBasic.c:3012
  #12 0x120174ac8 in TclExecuteByteCode
  (interp=0x120360480, codePtr=0x12045db40)
      at ./../generic/tclExecute.c:1279
  #13 0x120173bf8 in TclCompEvalObj (interp=0x120360480,
  objPtr=0x120463110)
      at ./../generic/tclExecute.c:917
  #14 0x12012f6c8 in Tcl_EvalObjEx (interp=0x120360480,
  objPtr=0x120463110,
      flags=0) at ./../generic/tclBasic.c:3907
  #15 0x1201c8c64 in TclObjInterpProc
  (clientData=0x120473db0,
      interp=0x120360480, objc=2, objv=0x11fffeed0)
      at ./../generic/tclProc.c:1074
  #16 0x12012dd90 in TclEvalObjvInternal
  (interp=0x120360480, objc=2,
      objv=0x11fffeed0,
      command=0x1204498ca "::tcltest::cleanupTests
  1\nreturn\n", length=26,
      flags=0) at ./../generic/tclBasic.c:3012
  #17 0x12012ee5c in Tcl_EvalEx (interp=0x120360480,
      script=0x120449030 "# all.tcl --\n#\n# This file
  contains a top-level script
   to run all of the Tk\n# tests.  Execute it by invoking
  \"source all.tcl\" when
  running tktest\n# in this directory.\n#\n# Copyright
  (c) 1998-1999 by Sc"...,
      numBytes=2235, flags=0) at ./../generic/tclBasic.c:3607
  #18 0x1201a6008 in Tcl_FSEvalFile (interp=0x120360480,
  pathPtr=0x1203ce780)
      at ./../generic/tclIOUtil.c:1355
  #19 0x1201a4c88 in Tcl_EvalFile (interp=0x120360480,
      fileName=0x11ffff238 "./../tests/all.tcl") at
  ./../generic/tclIOUtil.c:234
  #20 0x12004fe88 in Tk_MainEx (argc=3, argv=0x11ffff3a0,
      appInitProc=0x12002a500 <Tcl_AppInit>,
  interp=0x120360480)
      at /local/src/tk/unix/../generic/tkMain.c:234
  #21 0x12002a4d8 in main (argc=4, argv=0x11ffff398)
      at /local/src/tk/unix/tkAppInit.c:69


tkt_uuid: 570321ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Duplicate
title: tktest finalize segfault (text)
comment:
  tktest segaults during finalization (FreeRegexp) after
  running
  the tests in text.test on Linux/Alpha:

  (gdb) run ./../tests/all.tcl -file text.test
  Starting program: /local/src/tk/unix/./tktest
  ./../tests/all.tcl -file text.test
  Tk 8.4a5 tests running in interp: 
  /local/src/tk/unix/./tktest
  Tests running in working dir:  /local/src/tk/unix
  Sourcing files that match:  /local/src/tk/tests/text.test
  Tests began at Mon Jun 17 23:19:28 EDT 2002
  text.test

  ==== text-12.16 ConfigureText procedure FAILED
  ==== Contents of test case:

      # This test is non-portable because the window size
  will vary depending
      # on the font size, which can vary.

      catch {destroy .t2}
      toplevel .t2
      text .t2.t -width 20 -height 10
      pack append .t2 .t2.t top
      wm geometry .t2 +0+0
      update
      wm geometry .t2

  ---- Result was:
  150x140+5+21
  ---- Result should have been:
  150x140+0+0
  ==== text-12.16 FAILED


  ==== 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+5+21 150x140+5+21
  ---- Result should have been:
  20x10+0+0 150x140+0+0
  ==== text-15.2 FAILED


  Tests ended at Mon Jun 17 23:19:34 EDT 2002
  all.tcl:        Total   278     Passed  275     Skipped
  1       Failed  2
  Sourced 1 Test Files.
  Files with failing tests: text.test
  Number of tests skipped for each constraint:
          1       macOrPc

  Program received signal SIGSEGV, Segmentation fault.
  0x200005c17a8 in chunk_free (ar_ptr=0x20000770de0,
  p=0x1204b3870)
      at malloc.c:3121
  3121    malloc.c: No such file or directory.
  (gdb) bt
  #0  0x200005c17a8 in chunk_free (ar_ptr=0x20000770de0,
  p=0x1204b3870)
      at malloc.c:3121
  #1  0x200005c4574 in __libc_free (mem=0x20000770de0) at
  malloc.c:3023
  #2  0x12020a1a8 in TclpFree (cp=0x1204b3a90 "") at
  ./../generic/tclAlloc.c:702
  #3  0x120135f68 in Tcl_Free (ptr=0x1204b3a90 "")
      at ./../generic/tclCkalloc.c:1160
  #4  0x1201cb254 in FreeRegexp (regexpPtr=0x1204b2780)
      at ./../generic/tclRegexp.c:991
  #5  0x1201cb35c in FinalizeRegexp (clientData=0x0)
      at ./../generic/tclRegexp.c:1024
  #6  0x120172740 in Tcl_FinalizeThread () at
  ./../generic/tclEvent.c:906
  #7  0x120172520 in Tcl_Finalize () at
  ./../generic/tclEvent.c:804
  #8  0x120172108 in Tcl_Exit (status=0) at
  ./../generic/tclEvent.c:564
  #9  0x120137d88 in Tcl_ExitObjCmd (dummy=0x0,
  interp=0x120360480, objc=1,
      objv=0x120361c40) at ./../generic/tclCmdAH.c:667
  #10 0x12012dd90 in TclEvalObjvInternal
  (interp=0x120360480, objc=1,
      objv=0x120361c40, command=0x0, length=0, flags=0)
      at ./../generic/tclBasic.c:3012
  #11 0x120174ac8 in TclExecuteByteCode
  (interp=0x120360480, codePtr=0x12045d0a0)
      at ./../generic/tclExecute.c:1279
  #12 0x120173bf8 in TclCompEvalObj (interp=0x120360480,
  objPtr=0x1204630d0)
      at ./../generic/tclExecute.c:917
  #13 0x12012f6c8 in Tcl_EvalObjEx (interp=0x120360480,
  objPtr=0x1204630d0,
      flags=0) at ./../generic/tclBasic.c:3907
  #14 0x1201c8c64 in TclObjInterpProc
  (clientData=0x120473d40,
      interp=0x120360480, objc=2, objv=0x11fffeee0)
      at ./../generic/tclProc.c:1074
  #15 0x12012dd90 in TclEvalObjvInternal
  (interp=0x120360480, objc=2,
      objv=0x11fffeee0,
      command=0x12044988a "::tcltest::cleanupTests
  1\nreturn\n", length=26,
      flags=0) at ./../generic/tclBasic.c:3012
  #16 0x12012ee5c in Tcl_EvalEx (interp=0x120360480,
      script=0x120448ff0 "# all.tcl --\n#\n# This file
  contains a top-level script
   to run all of the Tk\n# tests.  Execute it by invoking
  \"source all.tcl\" when
  running tktest\n# in this directory.\n#\n# Copyright
  (c) 1998-1999 by Sc"...,
      numBytes=2235, flags=0) at ./../generic/tclBasic.c:3607
  #17 0x1201a6008 in Tcl_FSEvalFile (interp=0x120360480,
  pathPtr=0x1203ce740)
      at ./../generic/tclIOUtil.c:1355
  #18 0x1201a4c88 in Tcl_EvalFile (interp=0x120360480,
      fileName=0x11ffff248 "./../tests/all.tcl") at
  ./../generic/tclIOUtil.c:234
  #19 0x12004fe88 in Tk_MainEx (argc=3, argv=0x11ffff3b0,
      appInitProc=0x12002a500 <Tcl_AppInit>,
  interp=0x120360480)
      at /local/src/tk/unix/../generic/tkMain.c:234
  #20 0x12002a4d8 in main (argc=4, argv=0x11ffff3a8)
      at /local/src/tk/unix/tkAppInit.c:69


tkt_uuid: 570324ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Duplicate
title: tktest finalize segfault (select)
comment:
  tktest segfaults during finalization after running the
  tests
  in select.test with the "-file sel\*.test" option:

  (gdb) run ./../tests/all.tcl -file sel\*.test
  Starting program: /local/src/tk/unix/./tktest
  ./../tests/all.tcl -file sel\*.tes
  t
  Tk 8.4a5 tests running in interp: 
  /local/src/tk/unix/./tktest
  Tests running in working dir:  /local/src/tk/unix
  Sourcing files that match:  /local/src/tk/tests/sel*.test
  Tests began at Mon Jun 17 23:49:03 EDT 2002
  select.test

  Tests ended at Mon Jun 17 23:50:05 EDT 2002
  all.tcl:        Total   108     Passed  93      Skipped
  15      Failed  0
  Sourced 1 Test Files.
  Number of tests skipped for each constraint:
          8       altDisplay
          6       macOrPc
          1       nonPortable

  Program received signal SIGSEGV, Segmentation fault.
  0x200005c17a8 in chunk_free (ar_ptr=0x20000770de0,
  p=0x1203c2a00)
      at malloc.c:3121
  3121    malloc.c: No such file or directory.
  (gdb) bt
  #0  0x200005c17a8 in chunk_free (ar_ptr=0x20000770de0,
  p=0x1203c2a00)
      at malloc.c:3121
  #1  0x200005c4574 in __libc_free (mem=0x20000770de0) at
  malloc.c:3023
  #2  0x12020a1a8 in TclpFree (cp=0x1203c3360 " =\005 \001")
      at ./../generic/tclAlloc.c:702
  #3  0x120135f68 in Tcl_Free (ptr=0x1203c3360 " =\005 \001")
      at ./../generic/tclCkalloc.c:1160
  #4  0x120172754 in Tcl_FinalizeThread () at
  ./../generic/tclEvent.c:907
  #5  0x120172520 in Tcl_Finalize () at
  ./../generic/tclEvent.c:804
  #6  0x120172108 in Tcl_Exit (status=0) at
  ./../generic/tclEvent.c:564
  #7  0x120137d88 in Tcl_ExitObjCmd (dummy=0x0,
  interp=0x120360480, objc=1,
      objv=0x120361c40) at ./../generic/tclCmdAH.c:667
  #8  0x12012dd90 in TclEvalObjvInternal
  (interp=0x120360480, objc=1,
      objv=0x120361c40, command=0x0, length=0, flags=0)
      at ./../generic/tclBasic.c:3012
  #9  0x120174ac8 in TclExecuteByteCode
  (interp=0x120360480, codePtr=0x1204b7ec0)
      at ./../generic/tclExecute.c:1279
  #10 0x120173bf8 in TclCompEvalObj (interp=0x120360480,
  objPtr=0x1204630d0)
      at ./../generic/tclExecute.c:917
  #11 0x12012f6c8 in Tcl_EvalObjEx (interp=0x120360480,
  objPtr=0x1204630d0,
      flags=0) at ./../generic/tclBasic.c:3907
  #12 0x1201c8c64 in TclObjInterpProc
  (clientData=0x12046cb70,
      interp=0x120360480, objc=2, objv=0x11fffeee0)
      at ./../generic/tclProc.c:1074
  #13 0x12012dd90 in TclEvalObjvInternal
  (interp=0x120360480, objc=2,
      objv=0x11fffeee0,
      command=0x12044988a "::tcltest::cleanupTests
  1\nreturn\n", length=26,
      flags=0) at ./../generic/tclBasic.c:3012
  #14 0x12012ee5c in Tcl_EvalEx (interp=0x120360480,
      script=0x120448ff0 "# all.tcl --\n#\n# This file
  contains a top-level script
   to run all of the Tk\n# tests.  Execute it by invoking
  \"source all.tcl\" when
  running tktest\n# in this directory.\n#\n# Copyright
  (c) 1998-1999 by Sc"...,
      numBytes=2235, flags=0) at ./../generic/tclBasic.c:3607
  #15 0x1201a6008 in Tcl_FSEvalFile (interp=0x120360480,
  pathPtr=0x1203ce740)
      at ./../generic/tclIOUtil.c:1355
  #16 0x1201a4c88 in Tcl_EvalFile (interp=0x120360480,
      fileName=0x11ffff248 "./../tests/all.tcl") at
  ./../generic/tclIOUtil.c:234
  #17 0x12004fe88 in Tk_MainEx (argc=3, argv=0x11ffff3b0,
      appInitProc=0x12002a500 <Tcl_AppInit>,
  interp=0x120360480)
      at /local/src/tk/unix/../generic/tkMain.c:234
  #18 0x12002a4d8 in main (argc=4, argv=0x11ffff3a8)
      at /local/src/tk/unix/tkAppInit.c:69


tkt_uuid: 570748ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 29. Colormaps and Visuals
priority: 8
foundin: obsolete: 8.4a5
resolution: Works For Me
title: Tried to free a color that isn't alloc..
comment:
  Tcl 8.4a5 && Tk 8.4a5
  Windows XP

  Wierd things occur when using the remote desktop.

  If a TK application is started on the PC, then a remote
  desktop connection is made to that PC, the TK 
  application appears with only the frame padding visible.  
  All buttons, labels, menu's entry's, text.. etc. are 
  transparent.  I am able to see the background image 
  behind.  Moving, iconifiying, and use of the application 
  do not restore its appearance to normal.  The 
  application continues to work, menu items can be seen 
  and buttons (if you can guess where they are) still 
  function.  Occasionally while closeing the application by 
  clicking on the [x] button, top right corner, I get a Tk 
  crash.  A dailog appears with "Tried to free a color that 
  isn't allocated" and then a dialog with a memory 
  address failure appears.

  a simple sample script is all that is necessary to 
  reproduce.

  button .b
  pack .b -side top


tkt_uuid: 570764ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 8
foundin: obsolete: 8.4a5
resolution: Fixed
title: Withdrawn transients resurrected
comment:
  # The following demonstrates the problem;
  # enter interactively at the wish prompt

  toplevel .t ; wm transient .t .
  wm withdraw .t

  # Here, .t is withdrawn.
  wm iconify .   ;# Or use window manager controls ...
  wm deiconify . ;# ... ditto

  # .t reappears!  This should not happen

  --

  This happens on Unix/X11.

  Jeff reports that it also happens on Windows, and also
  affects the dropdown listbox for comboboxes.


tkt_uuid: 570902ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 65. Generic Window Operations
priority: 8
foundin: None
resolution: Accepted
title: Patch to fix crashes in XCloseIM
comment:
  After many hours of searching and patching, I think
  I have finally fixed all the X input context issues
  that were causing crashes in XCloseIM or XCloseDisplay.
  These crashes were a result of a bug in X, so
  our only hope is to work around them. I sent a
  patch for the problem into the XFree86 project.
  but that will not cover existing systems. The basic
  problem is that you need to call XDestroyIC for
  every input context created by XCreateIC. We were
  missing some for the "special" windows created
  by the send command and the clipboard. This lead
  to invalid memory accesses in XCloseIM and things
  could get random after that.

  My original approach was to just hack some
  XDestroyIC call in, but that was not the best
  approach. The real fix was to make it possible
  to invoke Tk_DestroyWindow on the special
  windows created by the send and clipboard
  methods. That required a little rework of
  the shutdown sequence since this was not
  handled before. I have tested this quite
  a bit, this patch should solve the
  strange crashing I have been seeing
  without introducing any others.


tkt_uuid: 571433ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Fixed
title: grid propagate does unneeded re-layout
comment:
  Tk Bug 220546 was not fixed quite right.
  This causes a re-layout when grid propagation is turned
  off even though
  it is already off.  The problem is in
  tk8.3.4/generic/tkGrid.c line 581:

          /* Only request a relayout if the propagation
  bit changes */

          if ((!propagate) ^
  (masterPtr->flags&DONT_PROPAGATE)) {
   
  The "if" condition is not right.  The first argument of
  ^ is 0 or 1 while
  the second argument is 0 or 2.


tkt_uuid: 571563ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Duplicate
title: 14 test suite failures on Win2000
comment:
  ran make test with latest cvs head and got 17 test 
  failures on Win2000 (after 'nmake clean', 'nmake 
  test' usiong vc++ 5).  (Note: I'm using the standard 
  desktop appearance etc).

  .\Release\tktest.exe ../tests/all.tcl  
  | .\Release\cat32.exe
  Tk 8.4a5 tests running in interp:  c:/tcl-
  source/tk8.4/win/Release/tktest.exe
  Tests running in working dir:  C:/Tcl-
  source/tk8.4/win
  Tests began at Thu Jun 20 10:07:51 AM GMT 
  Daylight Time 2002
  bell.test
  Bell should ring now ...
  bgerror.test
  bind.test
  bitmap.test
  border.test
  button.test
  canvImg.test
  canvPs.test
  canvRect.test
  canvText.test
  canvWind.test
  canvas.test
  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
  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

  ==== panedwindow-10.1 sash mark/sash dragto 
  interaction FAILED
  ==== Contents of test case:

      panedwindow .p -borderwidth 0 -sashpad 0 -
  sashwidth 4 -showhandle false
      .p add [frame .f -width 20 -height 20] [button .c]
      .p sash mark 0 10 10
      .p sash dragto 0 20 10
      set result [.p sash coord 0]
      destroy .p .f .c
      set result

  ---- Result was:
  28 0
  ---- Result should have been:
  30 0
  ==== panedwindow-10.1 FAILED


  ==== panedwindow-10.2 sash mark/sash dragto 
  interaction FAILED
  ==== Contents of test case:

      panedwindow .p -borderwidth 0 -sashpad 0 -
  sashwidth 4 -orient vertical  -sho
  whandle false
      .p add [frame .p.f -width 20 -height 20] 
  [button .p.c]
      .p sash mark 0 10 10
      .p sash dragto 0 10 20
      set result [.p sash coord 0]
      destroy .p .p.f .p.c
      set result

  ---- Result was:
  0 28
  ---- Result should have been:
  0 30
  ==== panedwindow-10.2 FAILED


  ==== panedwindow-12.1 moving sash changes 
  size of pane to left FAILED
  ==== Contents of test case:

      panedwindow .p -borderwidth 0 -sashpad 0 -
  sashwidth 4 -showhandle false
      .p add [frame .f -width 20 -height 20] 
  [button .c] -sticky nsew
      .p sash place 0 30 0
      pack .p
      update
      set result [winfo width .f]
      destroy .p .f .c
      set result

  ---- Result was:
  28
  ---- Result should have been:
  30
  ==== panedwindow-12.1 FAILED


  ==== panedwindow-12.4 moving sash changes 
  size of pane above FAILED
  ==== Contents of test case:

      panedwindow .p -showhandle false -
  borderwidth 0 -sashpad 0 -sashwidth 4  -or
  ient vertical
      .p add [frame .f -width 20 -height 10] 
  [button .c] -sticky nsew
      .p sash place 0 0 20
      pack .p
      update
      set result [winfo height .f]
      destroy .p .f .c
      set result

  ---- Result was:
  18
  ---- Result should have been:
  20
  ==== panedwindow-12.4 FAILED

  place.test
  raise.test
  safe.test
  scale.test
  scrollbar.test
  select.test
  send.test
  spinbox.test
  text.test
  textBTree.test
  textDisp.test
  skipping font-sensitive tests
  textImage.test
  textIndex.test
  textMark.test
  textTag.test
  textWind.test

  ==== textWind-10.1 EmbWinLayoutProc procedure 
  FAILED
  ==== Contents of test case:

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

  ---- Result was:
  1 10x20+45+5 1.5
  ---- Result should have been:
  1 10x20+40+5 1.5
  ==== textWind-10.1 FAILED


  ==== textWind-10.11 EmbWinLayoutProc 
  procedure, doesn't fit on line FAILED
  ==== Contents of test case:

      .t configure -wrap none
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 130 -height 20 -bg $color -bd 
  2 -relief raised
      .t window create 1.12 -window .f
      update
      list [.t bbox .f] [.t bbox 1.13]

  ---- Result was:
  {101 5 130 20} {231 6 8 17}
  ---- Result should have been:
  {89 5 126 20} {}
  ==== textWind-10.11 FAILED


  ==== textWind-11.1 EmbWinDisplayProc 
  procedure, geometry transforms FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      pack forget .t
      place .t -x 30 -y 50
      frame .f -width 30 -height 20 -bg $color
      .t window create 1.12 -window .f
      update
      winfo geom .f

  ---- Result was:
  30x20+131+55
  ---- Result should have been:
  30x20+119+55
  ==== textWind-11.1 FAILED


  ==== textWind-11.2 EmbWinDisplayProc 
  procedure, geometry transforms FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      pack forget .t
      place .t -x 30 -y 50
      frame .t.f -width 30 -height 20 -bg $color
      .t window create 1.12 -window .t.f
      update
      winfo geom .t.f

  ---- Result was:
  30x20+101+5
  ---- Result should have been:
  30x20+89+5
  ==== textWind-11.2 FAILED


  ==== textWind-13.1 EmbWinBboxProc procedure 
  FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 5 -height 5 -bg $color
      .t window create 1.2 -window .f -align top -
  padx 2 -pady 1
      update
      list [winfo geom .f] [.t bbox .f]

  ---- Result was:
  5x5+23+6 {23 6 5 5}
  ---- Result should have been:
  5x5+21+6 {21 6 5 5}
  ==== textWind-13.1 FAILED


  ==== textWind-13.2 EmbWinBboxProc procedure 
  FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 5 -height 5 -bg $color
      .t window create 1.2 -window .f -align center -
  padx 2 -pady 1
      update
      list [winfo geom .f] [.t bbox .f]

  ---- Result was:
  5x5+23+11 {23 11 5 5}
  ---- Result should have been:
  5x5+21+9 {21 9 5 5}
  ==== textWind-13.2 FAILED


  ==== textWind-13.9 EmbWinBboxProc procedure, 
  spacing options FAILED
  ==== Contents of test case:

      .t configure -spacing1 5 -spacing3 2
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 5 -height 5 -bg $color
      .t window create 1.2 -window .f -align center -
  padx 2 -pady 1
      update
      list [winfo geom .f] [.t bbox .f]

  ---- Result was:
  5x5+23+16 {23 16 5 5}
  ---- Result should have been:
  5x5+21+14 {21 14 5 5}
  ==== textWind-13.9 FAILED


  ==== textWind-16.2 EmbWinTextStructureProc 
  procedure FAILED
  ==== Contents of test case:

      .t configure -wrap none
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 30 -height 20 -bg $color
      .t window create 1.6 -window .f
      update
      set result {}
      lappend result [winfo geom .f] [.t bbox .f]
      frame .f2 -width 150 -height 30 -bd 2 -relief 
  raised
      pack .f2 -before .t
      update
      lappend result [winfo geom .f] [.t bbox .f]

  ---- Result was:
  30x20+53+5 {53 5 30 20} 30x20+53+35 {53 5 30 
  20}
  ---- Result should have been:
  30x20+47+5 {47 5 30 20} 30x20+47+35 {47 5 30 
  20}
  ==== textWind-16.2 FAILED


  ==== textWind-16.4 EmbWinTextStructureProc 
  procedure FAILED
  ==== Contents of test case:

      .t configure -wrap none
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .t.f -width 30 -height 20 -bg $color
      .t window create 1.6 -window .t.f
      update
      pack forget .t
      update
      list [winfo ismapped .t.f] [.t bbox .t.f]

  ---- Result was:
  1 {53 5 30 20}
  ---- Result should have been:
  1 {47 5 30 20}
  ==== textWind-16.4 FAILED

  tk.test
  unixButton.test
  skipping: Unix only tests...
  unixEmbed.test
  skipping: Unix only tests...
  unixFont.test
  skipping: Unix only tests...
  unixMenu.test
  skipping: Unix only tests...
  unixSelect.test
  skipping: Unix only tests...
  unixWm.test
  skipping: Unix only tests...
  util.test
  visual.test
  visual_bb.test
  winButton.test
  winClipboard.test
  winDialog.test
  winFont.test
  winMenu.test
  winSend.test
  skipping: Unimplemented send command
  winWm.test

  ==== winWm-1.4 TkWmMapWindow FAILED
  ==== Contents of test case:

      toplevel .t
      wm geometry .t +10+10
      update
      toplevel .t2
      wm geometry .t2 +40+10
      update
      set result [list [winfo x .t] [winfo x .t2]]
      destroy .t .t2
      set result

  ---- Result was:
  0 0
  ---- Result should have been:
  10 40
  ==== winWm-1.4 FAILED


  ==== winWm-2.4 TkpWmSetState FAILED
  ==== Contents of test case:

      set result {}
      toplevel .t
      wm geometry .t 150x50+10+10
      update
      lappend result [list [wm state .t] [wm geometry .t]]
      wm iconify .t
      update
      lappend result [list [wm state .t] [wm geometry .t]]
      wm geometry .t 200x50+10+10
      update
      lappend result [list [wm state .t] [wm geometry .t]]
      wm deiconify .t
      update
      lappend result [list [wm state .t] [wm geometry .t]]
      destroy .t
      set result

  ---- Result was:
  {normal 150x50+0+0} {iconic 150x50+0+0} {iconic 
  150x50+10+10} {normal 200x50+0+0
  }
  ---- Result should have been:
  {normal 150x50+10+10} {iconic 150x50+10+10} 
  {iconic 150x50+10+10} {normal 200x50
  +10+10}
  ==== winWm-2.4 FAILED


  ==== winWm-5.1 UpdateGeometryInfo: menu 
  resizing FAILED
  ==== Contents of test case:

      set result {}
      toplevel .t
      frame .t.f -width 150 -height 50 -bg red
      pack .t.f
      update
      set result [winfo height .t]
      menu .t.m
      .t.m add command -label foo
      .t conf -menu .t.m
      update
      lappend result [winfo height .t]
      .t.m add command -label "thisisreallylong"
      .t.m add command -label "thisisreallylong"
      update
      lappend result [winfo height .t]
      destroy .t
      set result

  ---- Result was:
  50 50 32
  ---- Result should have been:
  50 50 50
  ==== winWm-5.1 FAILED

  window.test
  winfo.test
  wm.test

  ==== wm-minsize-1.4 usage FAILED
  ==== Contents of test case:

      wm minsize .t

  ---- Result was:
  104 1
  ---- Result should have been:
  1 1
  ==== wm-minsize-1.4 FAILED

  xmfbox.test

  Tests ended at Thu Jun 20 10:09:08 AM GMT 
  Daylight Time 2002
  all.tcl:        Total   7503    Passed  6481    Skipped 
  1005    Failed  17
  Sourced 87 Test Files.
  Files with failing tests: panedwindow.test 
  textWind.test winWm.test xmfbox.test
  Number of tests skipped for each constraint:
          6       altDisplay
          7       emptyTest
          265     fonts
          2       knownBug
          310     macOnly
          15      macOrUnix
          61      nonPortable
          79      nonUnixUserInteraction
          3       pseudocolor
          1       tempNotPc
          237     unixOnly
          19      userInteraction
  stderr32
  Administrator@TRAPPER ~/tcl-source/tk8.4/win
  $


tkt_uuid: 571600ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 9 Immediate
foundin: obsolete: 8.4a5
resolution: Fixed
title: new wm bug with geometry in 8.4a5
comment:
  The latest 'wm' modifications have brought in a 
  new bug on Windows (Win2000 at least).

  proc test {} {
      catch {destroy .foo}
      toplevel .foo
      wm withdraw .foo
      wm geometry .foo 510x684+2+40
      wm deiconify .foo
      raise .foo
  }

  this procedure ignores the geometry specification 
  that has been given to the window.  In fact we can 
  reduce the above test to:

  proc test {} {
      catch {destroy .foo}
      toplevel .foo
      wm geometry .foo 510x684+2+40
  }

  Tk 8.3 and older versions of Tk 8.4 did not show 
  this bug.


tkt_uuid: 571937ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: TIP Implementation
resolution: Fixed
title: TIP #94: listbox -activestyle patch
comment:
  This is the implementation of -activestyle (TIP #94) for 
  the listbox.  This includes extra comments that may be 
  stripped out, but are left in for posterity here.


tkt_uuid: 572134ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 86. Test Tools
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Fixed
title: remove unnecessary tcltest dependence
comment:
  The building of the tktest executable depends on the
  existence of a tcltest executable and several of the
  object files that make up the Tcltest module.

  However, the tktest executable does not actually use
  any of the features provided by Tcltest.  This
  dependence is apparently due to the
  Tcltest_Init() call inside tkAppInit.c, that can be removed
  with no change in the behavior of tktest.

  I have mods implementing this fix, and I'll attach them
  here as soon as SF CVS come back to life and I
  can generate the patch.


tkt_uuid: 572428ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: TIP Implementation
resolution: Fixed
title: TIP #93 text get/delete enhancement
comment:
  Attached is an implementation of TIP #93, which 
  enhances text get/delete to allow for multiple range pairs.


tkt_uuid: 572909ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 9 Immediate
foundin: obsolete: 8.4a5
resolution: Works For Me
title: Wm crash on Win98
comment:
  The current 8.4b1 crashes in the test suite on Win98.

  The crash happens in wm-state-2.4, the update row.
  The crash is in tkWinWm.c line 3817 in
  UpdateGeometryInfo(). wmPtr is bad (= 0xdddddddd)

  Can't dig for more details right now...


tkt_uuid: 572948ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: UpdateGeometryInfo/transient crash
comment:
  Here are some test cases and a patch for crashing
  in the Win32 version of the wm command. It seems
  an idle time UpdateGeometryInfo is not getting
  canceled when the window is destroyed. The window
  has to be a transient so that a call to UpdateWrapper
  happens during destruction of the master. That
  UpdateWrapper call will clear the update pending
  bit but it does not cancel the actual callback.
  I think the patch included fixes the problem but
  I can't tell if it breaks anything else since
  TIP 47 has hosed the test results.


tkt_uuid: 572978ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: TIP Implementation
resolution: Accepted
title: Patch for TIP 47
comment:
  This patch includes the changes for TIP 47
  and the two little fixes needed to get
  everything working under Windows. This patch
  was integrated on 2002-06-14, this patch is
  just here so that someone can look at the
  patch in the future if needed.


tkt_uuid: 572995ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: Fix/test wm geom command
comment:
  This patch adds tests to the cross platform wm.test
  file while removing them from unixWm.test. These
  tests would have made it easier to catch bug
  571600, for example.

  This patch does make one change, in the sense
  that something that did not raise an error in
  the past will raise an error in 8.4.

  A geom command like:

  wm geom . +1+-10

  Is not valid. The implementation of ParseGeometry
  would incorrectly parse this y coord as a negative
  number even though the y coord sign (saved in
  the wmPtr->flags as WM_NEGATIVE_Y) would not
  be set.

  There were other variations like "+1--10" that
  would not raise an error while parsing but would
  not act correctly either. The docs for the geom
  command state that only a single - or + character
  can come before a x or y value.


tkt_uuid: 573681ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: tkConfig.sh.in substitution error
comment:
  On my HP-UX 11.00 system the configure script for tk
  results in a tkConfig.sh file that contains the
  following line.

  TK_XINCLUDES='# no special path needed'

  I believe this entry should be

  TK_XINCLUDES=''

  I down loaded tk from
  ftp://ftp.tcl.tk/pub/tcl/nightly-cvs/


tkt_uuid: 574075ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Duplicate
title: 8.4b1 font.test fails during make test
comment:
  something in the changes in the last 24 hrs or so for
  tk now causes this test suite failure:

  font.test

  ==== font-32.1 Tk_TextLayoutToPostscript: ensure buffer
  doesn't overflow FAILED
  ==== Contents of test case:

      # If there were a whole bunch of returns or tabs in
  a row, then the
      # temporary buffer could overflow and write on the
  stack.
      
      csetup
  "qwertyuiopasdfghjklzxcvbnm1234qwertyuiopasdfghjklzxcvbnm\n"
      .b.c itemconfig text -width 800
      .b.c insert text end
  "qwertyuiopasdfghjklzxcvbnm1234qwertyuiopasdfghjklzxcvb
  nm\n"
      .b.c insert text end
  "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
  \n\n\n"
      .b.c insert text end "end"
      set x [.b.c postscript]
      set i [string first "(qwerty" $x] 
      string range $x $i [expr {$i + 213}]

  ---- Result was:
  (qwertyuiopasdfghjklzxcvbnm1234qwertyuiopasdfghjklzxcvbnm)]
  [(qwertyuiopasdfghjklzxcvbnm1234qwertyuiopasdfghjklzxcvbnm)]
  [()]
  [()]
  [()]
  [()]
  [()]
  [()]
  [()]
  [()]
  [()]
  [()]
  [()]
  [()]
  [()]
  [()]
  [()]
  [()]
  [()]
  [()]
  [()
  ---- Result should have been:
  (qwertyuiopasdfghjklzxcvbnm1234qwertyuiopasdfghjklzxcvbnm)
  (qwertyuiopasdfghjklzxcvbnm1234qwertyuiopasdfghjklzxcvbnm)
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  ()
  (end)
  ==== font-32.1 FAILED


  Platform: SPARC Solaris 2.6
  Sun C compiler
  Desktop: CDE (Solaris 8)
  Tcl/Tk 8.4b1 built from the June 26, 2002 download of
  cvs head from activestate's ftp site.


tkt_uuid: 574128ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 68. Win Window Operations
priority: 7 High
foundin: None
resolution: Fixed
title: 'wm iconbitmap' for Windows.
comment:
  The attached smallpatch allows 'wm iconbitmap' to 
  work with Tk's ordinary bitmaps on WinTk.  
  (Currently only .ico or .icr files are supported).

  Now 'wm iconbitmap . hourglass' works, for 
  example.


tkt_uuid: 574326ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 22. Style Engine
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Fixed
title: compiler warning
comment:
  cc -c -O  -KPIC -I/local/src/tk/unix
  -I/local/src/tk/unix/../generic
  -I/local/src/tk/unix/../bitmaps
  -I/local/src/tcl/generic -I/usr/openwin/include
  -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1
  -DTCL_WIDE_INT_TYPE=long\ long -DHAVE_STRUCT_DIRENT64=1
  -DHAVE_STRUCT_STAT64=1 -DHAVE_TYPE_OFF64_T=1
  -D_REENTRANT=1 -D_POSIX_PTHREAD_SEMANTICS=1
  -DSTDC_HEADERS=1 -DHAVE_SYS_TIME_H=1
  -DTIME_WITH_SYS_TIME=1 -DHAVE_PW_GECOS=1     
  -DTCL_NO_DEPRECATED -DUSE_TCL_STUBS 
  /local/src/tk/unix/../generic/tkStyle.c
  "/local/src/tk/unix/../generic/tkStyle.c", line 15:
  warning: invalid white space character in directive


tkt_uuid: 574335ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Fixed
title: compiler warnings
comment:
  cc -c -O  -KPIC -I/local/src/tk/unix
  -I/local/src/tk/unix/../generic
  -I/local/src/tk/unix/../bitmaps
  -I/local/src/tcl/generic -I/usr/openwin/include
  -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1
  -DTCL_WIDE_INT_TYPE=long\ long -DHAVE_STRUCT_DIRENT64=1
  -DHAVE_STRUCT_STAT64=1 -DHAVE_TYPE_OFF64_T=1
  -D_REENTRANT=1 -D_POSIX_PTHREAD_SEMANTICS=1
  -DSTDC_HEADERS=1 -DHAVE_SYS_TIME_H=1
  -DTIME_WITH_SYS_TIME=1 -DHAVE_PW_GECOS=1     
  -DTCL_NO_DEPRECATED -DUSE_TCL_STUBS 
  /local/src/tk/unix/tkUnixFont.c
  "/local/src/tk/unix/tkUnixFont.c", line 1174: warning:
  argument #6 is incompatible with prototype:
          prototype: pointer to unsigned int :
  "/usr/openwin/include/X11/Xlib.h", line 2995
          argument : pointer to int
  "/local/src/tk/unix/tkUnixFont.c", line 1174: warning:
  argument #7 is incompatible with prototype:
          prototype: pointer to unsigned int :
  "/usr/openwin/include/X11/Xlib.h", line 2995
          argument : pointer to int
  "/local/src/tk/unix/tkUnixFont.c", line 1174: warning:
  argument #8 is incompatible with prototype:
          prototype: pointer to unsigned int :
  "/usr/openwin/include/X11/Xlib.h", line 2995
          argument : pointer to int
  "/local/src/tk/unix/tkUnixFont.c", line 1174: warning:
  argument #9 is incompatible with prototype:
          prototype: pointer to unsigned int :
  "/usr/openwin/include/X11/Xlib.h", line 2995
          argument : pointer to int


tkt_uuid: 575333ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 4
foundin: obsolete: 8.4a3
resolution: Duplicate
title: non-portable tests
comment:
  Solaris 9/Ultra 1/gcc 2.95.3

   ==== unixfont-2.4 TkpGetFontFromAttributes procedure:
  Helvetica  relatives FAILED
   ==== Contents of test case:

      set x {}
      lappend x [lindex [font actual {-family "Arial"}] 1]
      lappend x [lindex [font actual {-family "Geneva"}] 1]
      lappend x [lindex [font actual {-family
  "Helvetica"}] 1]

   ---- Result was:
   arial helvetica helvetica
   ---- Result should have been:
   helvetica helvetica helvetica
   ==== unixfont-2.4 FAILED

   ==== frame-14.1 labelframe labelwidget option FAILED
   ==== Contents of test case:

      # Test that label is moved in stacking order
      destroy .f .l
      label .l -text Mupp
      labelframe .f -labelwidget .l
      pack .f
      frame .f.f -width 50 -height 50
      pack .f.f
      update
      set res [list [winfo children .] [winfo width .f] 
  [expr {[winfo height .f] - [winfo height .l]}]]
      destroy .f .l
      set res

   ---- Result was:
   {.f .l} 58 52
   ---- Result should have been:
   {.f .l} 54 52
   ==== frame-14.1 FAILED

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

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

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


tkt_uuid: 577086ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 33. Generic Dialog Support
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: Fixed
title: bgerror dialog can be much too wide
comment:
  Example script:

  set err [string repeat "hello " 100]
  bgerror $err

  The dialog produced by 'bgerror' is several times 
  wider than the screen, so one can't even really see 
  the buttons properly (or at any rate, more than one 
  of them).

  The bgerror dialog should have a maximum width 
  of the size of the screen, at worst.

  (Note: this is on Windows, but I assume the same 
  on all platforms).


tkt_uuid: 577906ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 9 Immediate
foundin: obsolete: 8.4b1
resolution: Fixed
title: %P substitution not documented
comment:
  TIP 47 allegedly added a %P substitution to [bind] scripts,
  but it is not mentioned in doc/bind.n


tkt_uuid: 578165ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 86. Test Tools
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: Fixed
title: testthread used.
comment:
  Note that the testthread command shows up
  a few places in the Tk test suite.  These
  should migrate to use the Thread extensions.


tkt_uuid: 578207ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Invalid
title: [tk_popup] makes insertion cursor h
comment:
  L.S.

  The appended script exercises the hanging of the
  insertion cursor when using [tk_popup] in combination
  with [grab] under Windows OS's.

  When the insertion cursor hangs, it can be made ustuck
  by posting the popup menu a second time. This "every
  second time" has also been mentioned in a previous bug
  report concerning tk_popup (nr. 220928). This could
  indicate a common bug source).

  See also my posting to c.l.t. on 1-july-2002.

  Erik Leunissen.


  Reproducible script:
  ====================

  # This script exercises a hanging insertion cursor when
  using
  # [tk_popup] under MS Windows OS.

  # This script displays two entry widgets.

  # The insertion cursor will hang at some occasions.
  # These occasions are not entirely predictable to me, so
  # it is possible that you need to repeat the recipe below
  # several times before it happens to you too.
  #
  # 1. enter some characters in one of the widgets
  # 2. Select some of them (using keybord or mouse).
  # 3. Press the right mouse button to post the popup menu.
  # 3. Cut or Copy some characters (I think it is irrelevant
  #    whether or what you select in the popup menu, as long
  #    as you click the left mouse button somewhere on
  the screen).
  # 4. Paste the selection into the other entry widget
  using you mouse
  #    (which will fail if the insertion cursor doesn't
  follow you mouse.)
  #
  # If the insertion cursor doesn't hang immediately,
  then repeat this
  # sequence several times, using a different entry for
  the first click.
  #
  # Hunch: some grab problem?
  #

  package require Tk

  foreach e {.e1 .e2} {
      pack [entry $e]
  }


  set PopupMenu [menu .popup -tearoff 0]
  $PopupMenu add command -label "Cut    "
  $PopupMenu add command -label "Copy   "
  $PopupMenu add command -label "Paste  "


  proc PostPopupMenu {w x y} {
      global PopupMenu

      $PopupMenu entryconfigure 0 -command [list event
  generate $w <<Cut>>]
      $PopupMenu entryconfigure 1 -command [list event
  generate $w <<Copy>>]
      $PopupMenu entryconfigure 2 -command [list event
  generate $w <<Paste>>]
      tk_popup $PopupMenu [expr {[winfo rootx $w]+$x}]
  [expr {[winfo rooty $w]+$y}]

  }

  bind Entry <3> {
      PostPopupMenu %W %x %y
  }

  grab .


  # End reproducible script.


