# ticket

tkt_uuid: 1708823fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 29. Colormaps and Visuals
priority: 5 Medium
foundin: obsolete: 8.4.12
resolution: None
title: Wish crash on Windows XP when trying to free a color
comment:
  On Windows XP, Wish sometimes crashes after showing a dialog box stating "Tried to free a color that isn't allocated.".

  For me, this happens whilst running a Tk application when another application (e.g., a game) takes over the full screen and changes screen resolution (and probably screen color mode).

  Other users have seen this as well seemingly from time to time. Refer, e.g., to http://www.amsn-project.net/forums/viewtopic.php?t=584.

  This might well be a reoccurrence of bug #570748 (http://sourceforge.net/tracker/index.php?func=detail&aid=570748&group_id=12997&atid=112997).

  Regards,
  Sebastian


tkt_uuid: 1710633fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 7 High
foundin: obsolete: 8.5a6
resolution: Fixed
title: Tk uses deprecated syntax
comment:
  The files tk.tcl, choosedir.tcl, and
  comdlg.tcl in the Tk script library
  make use of the {expand} syntax, which
  is no longer approved.  


tkt_uuid: 1711985fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: strict-alias warnings
comment:
  /home/dgp/src/tk8.5a6/unix/../generic/tkConfig.c: In function ‘Tk_RestoreSavedOptions’:
  /home/dgp/src/tk8.5a6/unix/../generic/tkConfig.c:1441: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../generic/tkConfig.c:1445: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../generic/tkConfig.c:1453: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../generic/tkConfig.c:1457: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../generic/tkConfig.c:1461: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../generic/tkConfig.c:1465: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../generic/tkConfig.c:1469: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../generic/tkConfig.c:1473: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../generic/tkConfig.c:1477: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../generic/tkConfig.c:1481: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../generic/tkConfig.c:1485: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../generic/tkConfig.c:1490: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../generic/tkConfig.c:1494: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../generic/tkConfig.c:1498: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../generic/tkConfig.c:1502: warning: dereferencing type-punned pointer will break strict-aliasing rules


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


tkt_uuid: 1711989fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: type-punning warnings
comment:
  /home/dgp/src/tk8.5a6/unix/../generic/tkCanvPs.c: In function ‘TkCanvPostscriptCmd’:
  /home/dgp/src/tk8.5a6/unix/../generic/tkCanvPs.c:194: warning: type-punning to incomplete type might break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../generic/tkCanvPs.c:497: warning: type-punning to incomplete type might break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../generic/tkCanvPs.c:499: warning: type-punning to incomplete type might break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../generic/tkCanvPs.c:501: warning: type-punning to incomplete type might break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../generic/tkCanvPs.c:503: warning: type-punning to incomplete type might break strict-aliasing rules


tkt_uuid: 1711990fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: stubs strict-alias warning
comment:
  /home/dgp/src/tk8.5a6/unix/../generic/tkStubLib.c: In function ‘Tk_InitStubs’:
  /home/dgp/src/tk8.5a6/unix/../generic/tkStubLib.c:101: warning: dereferencing type-punned pointer will break strict-aliasing rules


tkt_uuid: 1711994fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: ttkLabel strict-aliasing
comment:
  compiler warning:

  /home/dgp/src/tk8.5a6/unix/../generic/ttk/ttkLabel.c: In function ‘LabelSetup’:
  /home/dgp/src/tk8.5a6/unix/../generic/ttk/ttkLabel.c:510: warning: dereferencing type-punned pointer will break strict-aliasing rules


  Also, unless the ttk files are
  going to be bug-free, we need
  to add maintainer categories for
  them, both here in the Tracker
  and in TIP 23.


tkt_uuid: 1711998fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: type-punned pointer
comment:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixEvent.c: In function ‘TkUnixDoOneXEvent’:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixEvent.c:540: warning: dereferencing type-punned pointer will break strict-aliasing rules


tkt_uuid: 1712001fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: strict-alias warnings
comment:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixRFont.c: In function ‘InitFont’:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixRFont.c:185: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixRFont.c: In function ‘TkpGetFontFamilies’:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixRFont.c:407: warning: missing sentinel in function call
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixRFont.c:409: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixRFont.c: In function ‘TkpGetSubFonts’:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixRFont.c:450: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixRFont.c:454: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixRFont.c:458: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixRFont.c: In function ‘TkpGetFontAttrsForChar’:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixRFont.c:506: warning: dereferencing type-punned pointer will break strict-aliasing rules


tkt_uuid: 1712008fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: ConvertSelection type-pun warning
comment:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixSelect.c: In function ‘ConvertSelection’:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixSelect.c:862: warning: dereferencing type-punned pointer will break strict-aliasing rules


tkt_uuid: 1712009fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: UnixSend strict-alias
comment:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixSend.c: In function ‘RegOpen’:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixSend.c:293: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixSend.c: In function ‘ValidateName’:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixSend.c:605: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixSend.c: In function ‘SendEventProc’:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixSend.c:1365: warning: dereferencing type-punned pointer will break strict-aliasing rules
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixSend.c: In function ‘TkpTestsendCmd’:
  /home/dgp/src/tk8.5a6/unix/../unix/tkUnixSend.c:1926: warning: dereferencing type-punned pointer will break strict-aliasing rules


tkt_uuid: 1712081fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 9 Immediate
foundin: obsolete: 8.5a6
resolution: Fixed
title: USE_OLD_IMAGE support broken
comment:
  The 2005-11-27 and 2006-03-16 commits
  to tkImage.c and tkImgPhoto.c have broken
  USE_OLD_IMAGE support for programs that
  embed Tk and do not use stubs.

  Such programs will set -DUSE_OLD_IMAGE
  when the *program code* is compiled.
  (That's distinct from when Tk is compiled).
  Thus they will want to link to the routines
  Tk_CreateOldPhotoImageFormat() and/or
  Tk_CreateOldImageType().  However since
  Tk's default compile does not define
  USE_OLD_IMAGE, the commits noted above
  will have these routines declared with
  MODULE_SCOPE, making them unavailable
  for linking, and the program will not
  link against a default build of Tk.


tkt_uuid: 1712098fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 7 High
severity: Minor
foundin: current: 8.6.0
resolution: None
title: Tk still needs Tcl source distro
comment:
  It appears that Tk will not
  compile because it can't
  find tcl.h if the Tcl source
  distribution has been moved
  or deleted.

  This is true even if we
  configure Tk with the
  --with-tcl= option pointing
  to the installed tclConfig.sh
  file, and even though, IIUC,
  steps have been taken to be
  sure that Tcl now installs
  its private headers.

  The headers are installed,
  tclConfig.sh notes where
  they are.  Tk ought to be
  able to build in this environment.


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

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

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

  thanks


tkt_uuid: 1714535fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: panedwindow geometry propagation
comment:
  It seems a [panedwindow] doesn't notice
  if the geometry requests from its panes 
  change, which can lead to surprises if 
  interactively writing commands for creating 
  a layout.

  The following procedure demonstrates the 
  problem in Tk 8.5a6 aqua (although I first 
  observed it in Tk 8.4.10 aqua):

  proc layout {} {
      set t [toplevel .test]
      pack [
         panedwindow $t.panes -orient vertical
      ] -expand true -fill both
      $t.panes add [frame $t.f1] -sticky nsew -minsize 50
      $t.panes add [frame $t.f2] -sticky nsew -minsize 50
      update
      canvas $t.f1.c  -width 200 -height 150 -relief solid -borderwidth 1
      canvas $t.f2.c  -width 200 -height 150 -relief solid -borderwidth 1
      pack $t.f1.c -expand true -fill both
      pack $t.f2.c -expand true -fill both
  }

  After calling [layout], the .test toplevel starts 
  out with a width of about 5 and a height of 
  about 100. In particular, [winfo reqwidth .test.f1] 
  is a bit over 200 as one would expect, but 
  [winfo width .test.f1] is 1.

  Removing the [update] makes the window open 
  with a more normal geometry, but e.g. when 
  debugging there may well be some trips through 
  the event loop between adding a frame as a pane 
  and completing its contents. I don't recall other 
  forms of geometry management being this 
  fragile.


tkt_uuid: 1715716fffffffffffffffffffffffffffffffff
type: Bug
status: Pending
subsystem: 69. Events
priority: 8
foundin: obsolete: 8.6b1
resolution: Fixed
title: window-2.9 deadlocks threaded Tk
comment:
  The test window-2.9 deadlocks threaded TkX11 and TkAqua (only generic code appears to be involved). Backtrace from TkX11 attached.
  The test succeeds in the unthreaded build.

  window-2.9 runs the following in a subprocess:
          toplevel .t1
          toplevel .t2
          update
          bind .t2 <Destroy> {puts "Destroy .t2" ; exit 1}
          bind .t1 <Destroy> {puts "Destroy .t1" ; exit 0}
          destroy .t2

  the deadlock occurs because Tcl_Finalize() is entered recursively, first from the [exit] in the .t2 <Destroy> handler, where it calls TkFinalizeThread(), which destroys all windows and causes the .t1 <Destroy> handler to fire, leading to a nested [exit] and deadlock on TclpInitLock() in Tcl_Finalize().


tkt_uuid: 1716117fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Accepted
title: improve genstubs/checkstubs
comment:
  With current HEAD of Tcl and Tk:

  $ cd tcl/unix
  $ ./configure
  $ make
  $ cd ../../tk/unix
  $ ./configure --disable-shared --with-tcl=../../tcl/unix
  $ make
  gcc -O2  -pipe    -Wl,--export-dynamic  tkAppInit.o -L/home/dgp/cvs/tk/unix -ltk8.5 \
                  -L/home/dgp/cvs/tcl/unix -ltcl8.5  -lX11 -lXss -lXext -lXft -lXrender -lfontconfig -lfreetype -lX11   -ldl  -lieee -lm  -Wl,-rpath,/home/dgp/i686/linux/lib -o wish
  /home/dgp/cvs/tk/unix/libtk8.5.a(tkStubLib.o): In function `Tk_InitStubs':
  tkStubLib.c:(.text+0x1f): undefined reference to `tclStubsPtr'
  collect2: ld returned 1 exit status
  make: *** [wish] Error 1

  If this is supposed to work, well,
  it doesn't.

  If it's not supposed to work, seems
  to me that Tk's configure script
  would be better off at least warning
  about the incompatible configure options.


tkt_uuid: 1716141fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
foundin: None
resolution: Fixed
title: unixfont-5.11 hangs TkAqua ATSUI text engine
comment:
  The test unixfont-5.11 causes TkAqua HEAD to hang in an infinite loop in the ATSUI text engine.
  The hang can be reproduced by running the following:
  label .l -font fixed -text "00" -wrap 1
  or even
  label .l -text "0" -wrap 1
  The hang does not occur in TkAqua core-8-4-branch, or in HEAD on other platforms, so it is specific to the ATSUI text engine.


tkt_uuid: 1716613fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: font-7.4 fails
comment:
  ---- Result was:
  0 {named font "xyz" doesn't exist}
  ---- Result should have been (exact matching):
  1 {named font "xyz" doesn't exist}
  ==== font-7.4 FAILED

  The FONT_DELETE stanza in tkFont.c
  does not appear to have anything in
  place to transfer an error in
  TkDeleteNamedFont to the return
  code of [font delete].


tkt_uuid: 1716639fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: None
resolution: Works For Me
title: Test cases not updated for TIP 145 font aliases
comment:
  TIP 145 defines new Tk font aliases. The font testcase are apparently not yet update for these new aliases:

  ---- Result was:
  font1 TkMenuFont ansifixed systemfixed TkHeadingFont device TkTooltipFont defaultgui TkTextFont ansi TkCaptionFont system TkSmallCaptionFont TkFixedFont TkIconFont
  ---- Result should have been (exact matching):
  font1
  ==== font-6.1 FAILED

  This causes failures for:

  font-6.1
  font-6.2
  font-6.3
  font-7.2
  font-11.2
  font-11.3
  font-11.4
  font-13.1
  font-17.4
   


tkt_uuid: 1717472fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Display Mac icons with Carbon IconServices API
comment:
  I would like to see Tk Aqua display Mac icons natively using the Carbon IconServices API (see http://developer.apple.com/documentation/Carbon/Reference/IconServices/index.html). I envision this working in the following fashion: given a file path, Carbon would display the correct icon/image data in Tk. 

  There appear to be at least rudimentary hooks for doing this already in the Tk Aqua code base, specifically tkMacOSXBitmap.c. Currently the code is mostly broken, and does not display many of the icons that were previously supported under Mac OS Classic (i.e. the "folder" bitmap). This could be an opportunity to fix and modernize the code at the same time. 


tkt_uuid: 1717475fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Mac-native bitmaps do not display under Aqua
comment:
  tkMacOSXBitmap.c defines several Mac-specific bitmaps that should display, but they do not. Sample code (tested under Wish-Aqua 8.4.14):

  label .a -bitmap questhead
   pack .l
  label .b -bitmap folder
  % pack .b
  label .c -bitmap stop
  pack .c


  This will display three labels. "questhead" displays properly. "folder," a Mac-specific color bitmap, does not display at all--the label is blank. "stop," a Mac-specific monochrome bitmap, displays correctly.

  It appears the color bitmaps under OS X are the ones that do not display correctly. 


tkt_uuid: 1717479fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Only GIF's appear correctly in menu
comment:
  Using the new custom MDEF under development in CVS HEAD for 8.5 and 8.4.15, it appears that only GIF's appear correctly. I tried to use PNG's via the tkpng and tkimg extensions and saw only white squares. 


tkt_uuid: 1717830fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Tk with Xft leaks using font commands
comment:
  Using CVS version of 2007/05/12
  I made a little script that increase memory by some MB...
  Usage :
  -Run it with wish : programe tells its PID
  -Do in a spearate console pmap <thepid>|grep total
  -Press enter in Tk console : wait until it says "Finished measure"
  -Redo pmap <thepid>|grep total : you will see that memory usage increased
  -Press enter again in Tk console : wait until it says "Finished metrics"
  -Redo pmap <thepid>|grep total : you will see that memory usage increased
  -Press enter again in Tk console to kill wish


tkt_uuid: 1719278fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: select test cases fail
comment:
  Platform: sparc solaris 9, latest tcl/tk cvs head, sun compiler, sun gnome desktop, windows xp exceed 10 x server

  The following errors are occurring:

  ==== select-10.1 ConvertSelection procedure, race with selection clear FAILED
  ==== Contents of test case:

      setup
      proc Ready {fd} {
          variable x
          lappend x [gets $fd]
      }
      set fd [open "|[list [interpreter] -geometry +0+0 -name tktest]" r+]
      puts $fd "puts foo; [loadTkCommand]; flush stdout"
      flush $fd
      gets $fd
      fileevent $fd readable [list Ready $fd]
      set selValue "Just a simple test"
      set selInfo ""
      selection handle .f1 {handler STRING}
      update
      puts $fd {puts "[catch {selection get} msg] $msg"; puts **DONE**; flush stdo
  ut}
      flush $fd
      after 200
      selection own .
      set x {}
      vwait [namespace which -variable x]
      puts $fd {exit}
      flush $fd
      # Don't understand why, but the [loadTkCommand] above causes
      # a "broken pipe" error when Tk was actually [load]ed in the child.
      catch {close $fd}
      lappend x $selInfo

  ---- Result was:
  {1 PRIMARY selection doesn't exist or form "STRING" not defined} {STRING 0 4000}
  ---- Result should have been (exact matching):
  {1 PRIMARY selection doesn't exist or form "STRING" not defined} {}
  ==== select-10.1 FAILED

  ==== select-10.2 ConvertSelection procedure FAILED
  ==== Contents of test case:

      setup
      setupbg
      set selValue [string range $longValue 0 3999]
      set selInfo ""
      selection handle .f1 {handler STRING}
      set result ""
      lappend result [dobg {selection get}]
      cleanupbg
      lappend result $selInfo

  ---- Result was:
  Aa.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ba.1a.2a.3a.4a.5a.6a.7a.8a.9a.10
  a.11a.12a.13a.14Ca.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Da.1a.2a.3a.4a.5
  a.6a.7a.8a.9a.10a.11a.12a.13a.14Ea.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14
  Fa.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ga.1a.2a.3a.4a.5a.6a.7a.8a.9a.10
  a.11a.12a.13a.14Ha.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ia.1a.2a.3a.4a.5
  a.6a.7a.8a.9a.10a.11a.12a.13a.14Ka.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14
  La.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ma.1a.2a.3a.4a.5a.6a.7a.8a.9a.10
  a.11a.12a.13a.14Na.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ab.1b.2b.3b.4b.5
  b.6b.7b.8b.9b.10b.11b.12b.13b.14Bb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14
  Cb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Db.1b.2b.3b.4b.5b.6b.7b.8b.9b.10
  b.11b.12b.13b.14Eb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Fb.1b.2b.3b.4b.5
  b.6b.7b.8b.9b.10b.11b.12b.13b.14Gb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14
  Hb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Ib.1b.2b.3b.4b.5b.6b.7b.8b.9b.10
  b.11b.12b.13b.14Kb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Lb.1b.2b.3b.4b.5
  b.6b.7b.8b.9b.10b.11b.12b.13b.14Mb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14
  Nb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Ac.1c.2c.3c.4c.5c.6c.7c.8c.9c.10
  c.11c.12c.13c.14Bc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Cc.1c.2c.3c.4c.5
  c.6c.7c.8c.9c.10c.11c.12c.13c.14Dc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14
  Ec.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Fc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10
  c.11c.12c.13c.14Gc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Hc.1c.2c.3c.4c.5
  c.6c.7c.8c.9c.10c.11c.12c.13c.14Ic.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14
  Kc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Lc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10
  c.11c.12c.13c.14Mc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Nc.1c.2c.3c.4c.5
  c.6c.7c.8c.9c.10c.11c.12c.13c.14Ad.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14
  Bd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Cd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10
  d.11d.12d.13d.14Dd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Ed.1d.2d.3d.4d.5
  d.6d.7d.8d.9d.10d.11d.12d.13d.14Fd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14
  Gd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Hd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10
  d.11d.12d.13d.14Id.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Kd.1d.2d.3d.4d.5
  d.6d.7d.8d.9d.10d.11d.12d.13d.14Ld.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14
  Md.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Nd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10
  d.11d.12d.13d.14Ae.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Be.1e.2e.3e.4e.5
  e.6e.7e.8e.9e.10e.11e.12e.13e.14Ce.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14
  De.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Ee.1e.2e.3e.4e.5e.6e.7e.8e.9e.10
  e.11e.12e.13e.14Fe.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Ge.1e.2e.3e.4e.5
  e.6e.7e.8e.9e.10e.11e.12e.13e.14He.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14
  Ie.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Ke.1e.2e.3e.4e.5e.6e.7e.8e.9e.10
  e.11e.12e.13e.14Le.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Me.1e.2e.3e.4e.5
  e.6e.7e.8e.9e.10e.11e.12e.13e.14Ne.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14
  Af.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Bf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10
  f.11f.12f.13f.14Cf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Df.1f.2f.3f.4f.5
  f.6f.7f.8f.9f.10f.11f.12f.13f.14Ef.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14
  Ff.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Gf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10
  f.11f.12f.13f.14Hf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14If.1f.2f.3f.4f.5
  f.6f.7f.8f.9f.10f.11f.12f.13f.14Kf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14
  Lf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Mf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10
  f.11f.12f.13f.14Nf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Ag.1g.2g.3g.4g.5
  g.6g.7g.8g.9g.10g.11g.12g.13g.14Bg.1g.2g.3g.4g.5g.6g.7g.8g.9g.10g.11g.12g.13g.14
  Cg.1g.2g.3g.4g.5g.6g.7g.8g.9g.10g.11g.12g.13g.14Dg.1g.2g.3g.4g.5g.6g.7g.8g.9g.10
  g.11g.12g.13g.14Eg.1g.2g.3g.4g.5g.6g.7g.8g.9g.10g.11g.12g.13g.14Fg.1g.2g.3g.4g.5
   {STRING 0 4000 STRING 4000 4000 STRING 0 4000 STRING 4000 4000 STRING 0 4000 ST
  RING 4000 4000 STRING 0 4000 STRING 4000 4000}
  ---- Result should have been (exact matching):
  Aa.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ba.1a.2a.3a.4a.5a.6a.7a.8a.9a.10
  a.11a.12a.13a.14Ca.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Da.1a.2a.3a.4a.5
  a.6a.7a.8a.9a.10a.11a.12a.13a.14Ea.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14
  Fa.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ga.1a.2a.3a.4a.5a.6a.7a.8a.9a.10
  a.11a.12a.13a.14Ha.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ia.1a.2a.3a.4a.5
  a.6a.7a.8a.9a.10a.11a.12a.13a.14Ka.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14
  La.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ma.1a.2a.3a.4a.5a.6a.7a.8a.9a.10
  a.11a.12a.13a.14Na.1a.2a.3a.4a.5a.6a.7a.8a.9a.10a.11a.12a.13a.14Ab.1b.2b.3b.4b.5
  b.6b.7b.8b.9b.10b.11b.12b.13b.14Bb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14
  Cb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Db.1b.2b.3b.4b.5b.6b.7b.8b.9b.10
  b.11b.12b.13b.14Eb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Fb.1b.2b.3b.4b.5
  b.6b.7b.8b.9b.10b.11b.12b.13b.14Gb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14
  Hb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Ib.1b.2b.3b.4b.5b.6b.7b.8b.9b.10
  b.11b.12b.13b.14Kb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Lb.1b.2b.3b.4b.5
  b.6b.7b.8b.9b.10b.11b.12b.13b.14Mb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14
  Nb.1b.2b.3b.4b.5b.6b.7b.8b.9b.10b.11b.12b.13b.14Ac.1c.2c.3c.4c.5c.6c.7c.8c.9c.10
  c.11c.12c.13c.14Bc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Cc.1c.2c.3c.4c.5
  c.6c.7c.8c.9c.10c.11c.12c.13c.14Dc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14
  Ec.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Fc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10
  c.11c.12c.13c.14Gc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Hc.1c.2c.3c.4c.5
  c.6c.7c.8c.9c.10c.11c.12c.13c.14Ic.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14
  Kc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Lc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10
  c.11c.12c.13c.14Mc.1c.2c.3c.4c.5c.6c.7c.8c.9c.10c.11c.12c.13c.14Nc.1c.2c.3c.4c.5
  c.6c.7c.8c.9c.10c.11c.12c.13c.14Ad.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14
  Bd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Cd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10
  d.11d.12d.13d.14Dd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Ed.1d.2d.3d.4d.5
  d.6d.7d.8d.9d.10d.11d.12d.13d.14Fd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14
  Gd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Hd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10
  d.11d.12d.13d.14Id.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Kd.1d.2d.3d.4d.5
  d.6d.7d.8d.9d.10d.11d.12d.13d.14Ld.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14
  Md.1d.2d.3d.4d.5d.6d.7d.8d.9d.10d.11d.12d.13d.14Nd.1d.2d.3d.4d.5d.6d.7d.8d.9d.10
  d.11d.12d.13d.14Ae.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Be.1e.2e.3e.4e.5
  e.6e.7e.8e.9e.10e.11e.12e.13e.14Ce.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14
  De.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Ee.1e.2e.3e.4e.5e.6e.7e.8e.9e.10
  e.11e.12e.13e.14Fe.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Ge.1e.2e.3e.4e.5
  e.6e.7e.8e.9e.10e.11e.12e.13e.14He.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14
  Ie.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Ke.1e.2e.3e.4e.5e.6e.7e.8e.9e.10
  e.11e.12e.13e.14Le.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14Me.1e.2e.3e.4e.5
  e.6e.7e.8e.9e.10e.11e.12e.13e.14Ne.1e.2e.3e.4e.5e.6e.7e.8e.9e.10e.11e.12e.13e.14
  Af.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Bf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10
  f.11f.12f.13f.14Cf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Df.1f.2f.3f.4f.5
  f.6f.7f.8f.9f.10f.11f.12f.13f.14Ef.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14
  Ff.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Gf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10
  f.11f.12f.13f.14Hf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14If.1f.2f.3f.4f.5
  f.6f.7f.8f.9f.10f.11f.12f.13f.14Kf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14
  Lf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Mf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10
  f.11f.12f.13f.14Nf.1f.2f.3f.4f.5f.6f.7f.8f.9f.10f.11f.12f.13f.14Ag.1g.2g.3g.4g.5
  g.6g.7g.8g.9g.10g.11g.12g.13g.14Bg.1g.2g.3g.4g.5g.6g.7g.8g.9g.10g.11g.12g.13g.14
  Cg.1g.2g.3g.4g.5g.6g.7g.8g.9g.10g.11g.12g.13g.14Dg.1g.2g.3g.4g.5g.6g.7g.8g.9g.10
  g.11g.12g.13g.14Eg.1g.2g.3g.4g.5g.6g.7g.8g.9g.10g.11g.12g.13g.14Fg.1g.2g.3g.4g.5
   {STRING 0 4000 STRING 4000 4000 STRING 0 4000 STRING 4000 4000}
  ==== select-10.2 FAILED
  ==== select-11.1 TkSelPropProc procedure FAILED
  ==== Contents of test case:

      setup
      setupbg
      set selValue $longValue
      set selInfo ""
      selection handle -type TEST .f1 { handler TEST }
      selection handle -type STRING .f1 { reallyBadHandler .f1 STRING }
      set result ""
      set pass 0
      lappend result [dobg {selection get}]
      cleanupbg
      lappend result $selInfo

  ---- Result was:
  {PRIMARY selection doesn't exist or form "STRING" not defined} {.f1 STRING 0 400
  0 .f1 STRING 4000 4000 .f1 STRING 8000 4000 .f1 STRING 12000 4000 .f1 STRING 160
  00 4000 .f1 STRING 0 4000 .f1 STRING 4000 4000}
  ---- Result should have been (exact matching):
  {selection owner didn't respond} {.f1 STRING 0 4000 .f1 STRING 4000 4000 .f1 STR
  ING 8000 4000 .f1 STRING 12000 4000 .f1 STRING 16000 4000 .f1 STRING 0 4000 .f1 
  STRING 4000 4000}
  ==== select-11.1 FAILED


tkt_uuid: 1719282fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: unixSelect test suite errors
comment:
  Platform: sun sparc solaris 9, sun c compiler, tcl/tk cvs head, windows xp pro and exceed 10 X server


  ==== unixSelect-1.4 TkSelGetSelection procedure: simple i18n text, iso2022 FAILE
  D
  ==== Contents of test case:

      setupbg
      setup
      selection handle -type COMPOUND_TEXT -format COMPOUND_TEXT .  {handler COMPO
  UND_TEXT}
      selection own .
      set selValue \u00fc\u0444
      set selInfo {}
      set result [dobg {
          set x [selection get -type COMPOUND_TEXT]
          list [string equal \u00fc\u0444 $x]  [string length $x] [string byteleng
  th $x]
      }]
      cleanupbg
      lappend result $selInfo

  ---- Result was:
  1 2 4 {COMPOUND_TEXT 0 4000 COMPOUND_TEXT 0 4000}
  ---- Result should have been (exact matching):
  1 2 4 {COMPOUND_TEXT 0 4000}
  ==== unixSelect-1.4 FAILED]

  ==== unixSelect-1.5 TkSelGetSelection procedure: INCR i18n text, iso2022 FAILED
  ==== Contents of test case:

      # This test is subtle.  The selection ends up getting fetched twice by
      # Tk:  once to compute the length, and again to actually send the data.
      # The first time through, we don't convert the data to ISO2022, so the
      # buffer boundaries end up being different in the two passes.

      setupbg
      setup
      selection handle -type COMPOUND_TEXT -format COMPOUND_TEXT .  {handler COMPO
  UND_TEXT}
      selection own .
      set selValue [string repeat x 3999]\u00fc\u0444[string repeat x 3999]
      set selInfo {}
      set result [dobg {
          set x [selection get -type COMPOUND_TEXT]
          list [string equal  [string repeat x 3999]\u00fc\u0444[string repeat x 3
  999] $x]  [string length $x] [string bytelength $x]
      }]
      cleanupbg
      lappend result $selInfo

  ---- Result was:
  1 8000 8002 {COMPOUND_TEXT 0 4000 COMPOUND_TEXT 4000 3999 COMPOUND_TEXT 7998 400
  0 COMPOUND_TEXT 0 4000 COMPOUND_TEXT 4000 3999 COMPOUND_TEXT 7998 4000 COMPOUND_
  TEXT 0 4000 COMPOUND_TEXT 4000 3998 COMPOUND_TEXT 7997 4000}
  ---- Result should have been (exact matching):
  1 8000 8002 {COMPOUND_TEXT 0 4000 COMPOUND_TEXT 4000 3999 COMPOUND_TEXT 7998 400
  0 COMPOUND_TEXT 0 4000 COMPOUND_TEXT 4000 3998 COMPOUND_TEXT 7997 4000}
  ==== unixSelect-1.5 FAILED
  ==== unixSelect-1.6 TkSelGetSelection procedure: simple i18n text, iso2022 FAILE
  D
  ==== Contents of test case:

      setupbg
      setup
      selection handle -type COMPOUND_TEXT -format COMPOUND_TEXT .  {handler COMPO
  UND_TEXT}
      selection own .
      set selValue \u00fc\u0444
      set selInfo {}
      set result [dobg {
          set x [selection get -type COMPOUND_TEXT]
          list [string equal \u00fc\u0444 $x]  [string length $x] [string byteleng
  th $x]
      }]
      cleanupbg
      lappend result $selInfo

  ---- Result was:
  1 2 4 {COMPOUND_TEXT 0 4000 COMPOUND_TEXT 0 4000}
  ---- Result should have been (exact matching):
  1 2 4 {COMPOUND_TEXT 0 4000}
  ==== unixSelect-1.6 FAILED


tkt_uuid: 1719285fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Invalid
title: unixwm test suite 4.x failures
comment:
  platform: sparc solaris 9, sun c compiler, latest tcl/tk cvs head, windows xp pro/exceed 10 x server

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

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

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

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

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

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

  ---- Result was:
  0 0 150 300
  ---- Result should have been (exact matching):
  50 -100 150 300
  ==== unixWm-48.13 FAILED
  ==== unixWm-50.1 Tk_CoordsToWindow procedure, finding a toplevel, x-coords FAILE
  D
  ==== Contents of test case:

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

  ---- Result was:
  {} {} .t .t .t .t .t .t
  ---- Result should have been (exact matching):
  {} {} .t {} .t2 .t2 {} .t
  ==== unixWm-50.1 FAILED
  ==== unixWm-50.8 Tk_CoordsToWindow procedure, more basics FAILED
  ==== Contents of test case:

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

  ---- Result was:
  .t.f .t.f.f .t {} {}
  ---- Result should have been (exact matching):
  .t .t.f .t.f.f .t {}
  ==== unixWm-50.8 FAILED
  ==== unixWm-50.10 Tk_CoordsToWindow procedure, unmapped windows FAILED
  ==== Contents of test case:

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

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


tkt_uuid: 1721393fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Release Notes
priority: 9 Immediate
foundin: obsolete: 8.5a6
resolution: Duplicate
title: tk/unix/README typo
comment:
  In section (d) of the README, after talking about Tk, the verbage talks about running a configure that configures Tcl for your system. It should say Tk.

  Also, I suspect that in the Note: in section (d), the text should read

  It is not safe to change the Makefile to use cc after configure is run. 

  The previous sentence was emphasizing that one now has to set the CC environment variable if they want to use cc instead of gcc - this change would be more consistent with what seems to be the intent of the note.

  In section (g), the word "directoryies" should be "directories".


tkt_uuid: 1722072fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 6
foundin: obsolete: 8.5a6
resolution: Invalid
title: Large text truncates/corrupts clipboard
comment:
  tcl_patchLevel: 8.5a6
  OS Platform and Version: Linux, Slackware 11

  Problem Behavior: when trying to insert text into the OS's (or graphic server's) clipboard with Tk, too much text will eventually get corrupted. Instead of the text, the clipboard will contain 2 or 3 random characters, totally unrelated to the expected content. Small portions of text are unaffected. The text must be large enough (at least 40 to 100 lines give or take) to trigger the bug.

  Expected Behavior: any text should be inserted correctly into the operating system's (or graphic server's) clipboard with Tk, regardless of the amount.

  Concise Code Sample:

  clipboard clear -displayof .
  clipboard append -displayof . "$lots_of_text"

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


tkt_uuid: 1723059fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: Entryconfigure destroys submenus
comment:
  When creating a toplevel menubar (. configure -menu ...) and assigning it the same cascade submenu as it has and then replacing submenu with another the previous submenu is destroyed!

  Bad explanation, attached script demonstrates behaviour.


tkt_uuid: 1723362fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 40. Bitmap Images
priority: 8
foundin: obsolete: 8.4.14
resolution: Accepted
title: tkWinDraw transparent bitmap problem and fix
comment:
  XCopyPlane in tk/win/tkWinDraw.c is used to draw
  bitmap images.  For some image types SetBkColor and
  SetTextColor are set.  For bitmap images with a
  transparent background (case 2 in the code), the
  SetBkColor and SetTextColor are not set.  But those
  settings can affect the output of transparent images,
  in ways that are not clearly documented in MSDN.

  The problem is not always seen.  It does not seem to
  affect tcl/tk core widgets which almost always draw
  via an off-screen pixmap.  But the tktable extension
  legitimately draws directly to the on-screen window
  for performance, and can get often get corrupted
  transparent bitmaps - it also seems to depends on the
  type of wish build, what has been drawn previously,
  the state of ms-windows, day of the week etc.

  The attached tktable-bitmap1.tcl script demonstrates
  the problem using tktable.  The second bitmap is
  supposed to be a red square with rounded corners, but
  on my system is displayed reversed.

  The fix is simply to reset BkColor and TextColor for
  transparent bitmaps, as shown in the following patch. 
  Note that the background/foreground settings are
  counter-intuitive.


  --- tkWinDraw.c Tue May 22 11:37:46 2007
  +++ tkWinDraw-update.c    Tue May 22 11:38:07 2007
  @@ -415,11 +415,14 @@
              /*
               * Case 2: transparent bitmaps are handled by setting the
               * destination to the foreground color whenever the source
  -            * pixel is set.
  +            * pixel is set.  We need to reset the BkColor and TextColor,
  +            * because they affect bitmap colour mapping.
               */
   
              fgBrush = CreateSolidBrush(gc->foreground);
              oldBrush = SelectObject(destDC, fgBrush);
  +           SetBkColor(destDC, RGB(255,255,255));
  +           SetTextColor(destDC, RGB(0,0,0));
              BitBlt(destDC, dest_x, dest_y, width, height, srcDC, src_x, src_y,
                      MASKPAT);
              SelectObject(destDC, oldBrush);



  I'll attach updated source files for the current CVS
  HEAD and core-8-4-15 branches.  I have been using the
  fix with tk8.14 for several weeks with no problems.


tkt_uuid: 1723622fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 8
foundin: obsolete: 8.5a6
resolution: Fixed
title: Tcl_InitStubs calls demand lockstep with Tcl
comment:
  All the Tcl_InitStubs() calls
  in the Tk HEAD look like this:

    Tcl_InitStubs(interp, TCL_PATCH_LEVEL, 1)

  Even ignoring the controversy over how
  -exact matching has been revised (Tcl
  Bug 1578344), this call results in too
  tight a demand for Tcl release compatibility.
  If no changes are made to the way the codes are currently written, we will one day compile some
  Tk source code against an 8.5.1 tcl.h file, and
  the resulting shared library will only be able
  to [load] into an interp in the range 8.5.1-8.5.2.
  In particular, this shared library would 
  not [load] into a Tcl 8.5.2 interp, which
  by tradition would be the next release of Tcl.

  The implication is that a Tk build is only
  good for a single release of Tcl, which
  means the use of stubs is pretty nearly
  pointless.

  I think the proper calls that would take
  advantage of the special provisions
  made for -exact matching ought to be:

    Tcl_InitStubs(interp, TCL_VERSION, 1)

  Combining that call with the special -exact
  matching rules would produce a shared library
  that will [load] into any Tcl 8.5* interp, which
  is the level of release compatibility we have
  supported between Tk and Tcl up to now.

  Feel free to drop in the chat if further
  discussion is needed to understand me.

  If it's really intended to lockdown each
  Tk release to exactly one Tcl release, we
  really ought to publicize that.  I'll
  try my best to talk you out of it.


tkt_uuid: 1723812fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 9 Immediate
foundin: obsolete: 8.5a7
resolution: Fixed
title: TCL_ALPHA_RELEASE used before #define-d
comment:
  Line 50 of tk.h:

  #define TK_RELEASE_LEVEL        TCL_ALPHA_RELEASE

  comes before line 57:

  #   include <tcl.h>

  which means every program that has

  #include <tk.h>

  must first have

  #include <tcl.h>

  That's not so bad as a requirement, but
  lines 56-61 of tk.h indicate that's
  not what's been intended.

  Obvious fix is a bit of line shifting.


tkt_uuid: 1724460fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 60. [tk_setPalette]
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: Fixed
title: tk_setPalette background fails
comment:
  I tested a prerelease of TkAqua provided by Daniel Steffen which included some very welcome improvements to Aqua support. The one bug I found was this (running from wish):

  % tk_setPalette background white
  unknown color name ""

  Repeating the command gives a different error:

  % tk_setPalette background white
  window name "___tk_set_palette" already exists in parent


tkt_uuid: 1724841fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 80. Release Notes
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: Fixed
title: README typos with fix
comment:
  I'm attaching a patch to this bug report. The tk8.4.15/unix/README file has a few typos, and I've fixed them.


tkt_uuid: 1725782fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: -joinstyle default documentation
comment:
  The documentation of the line and polygon canvas items says the default for the -joinstyle option is "miter". However, it is from both source and behaviour clear that the default is rather "round".


tkt_uuid: 1730099fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: Set aqua button -state normal sometimes results in active
comment:
  8.5a6, a5, 8.4.9

  button .b1 -text "Left" -command { .b1 configure -state disabled ; .b2 configure -state normal } -state disabled
  button .b2 -text "Right" -command { .b1 configure -state normal ; .b2 configure -state disabled } -state disabled
  pack .b1 -side left
  pack .b2 -side right
  .b2 configure -state normal

  Here, pushing one button switches state of both (common in a "forward-back" history situation).  However, pushing the buttons alternately will result in, starting second iteration, the newly normalized one erroneously set to active state (highlighted w/grey).

  The following patch against tkMacOSXButton.c fixes it, though I can't claim to know why...

  ==========
  --- tkMacOSXButton_orig.c       2007-06-02 15:06:06.000000000 -0400
  +++ tkMacOSXButton.c    2007-06-02 19:43:19.000000000 -0400
  @@ -986,6 +986,11 @@
   
          HiliteControl(mbPtr->control, kControlNoPart);
   
  +        // sometimes it needs to be hit over the head for some reason
  +       if (butPtr->state == STATE_NORMAL
  +               && GetControlHilite(mbPtr->control) == kControlButtonPart)
  +           HiliteControl(mbPtr->control, kControlNoPart);
  +
          if (butPtr->state == STATE_ACTIVE) {
              if (mbPtr->params.isBevel) {
                  HiliteControl(mbPtr->control, kControlButtonPart);
  ==========


tkt_uuid: 1731348fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 43. Photo Image|PPM
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: Fixed
title: photo man page misleading about base64 support
comment:
  The photo(n) man page says

   -data string
                Specifies the contents of the image as a string.  The string can contain base64 encoded data or binary data. [...]

  But this is only true for GIF images. The PPM handler completely lacks the base64 support.

  kind regards
  -- 
  Matthias Kraft


tkt_uuid: 1731355fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: None
title: tile display bug in TkAqua 8.4.15 preview
comment:
  In the TkAqua-8.4.15-preview (standalone) version tile-0.8.0 elements are not displayed properly. Sometimes it randomly appears correctly. But mostly just black boxes or boxes with random patterns are displayed.


tkt_uuid: 1731734fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: Out of Date
title: Aqua preview 8.4.15 menubutton cascade menus don't display
comment:
  In the 8.4.15 Aqua preview from DAS, cascade menus on menubuttons don't display on mouseover. You can't get to the cascaded menus.

  They do work fine on menus in the menubar, only problems are on menus attached to menubuttons.



  contact me at:
  m dot wayne dot davis at gmail tod com
  for any questions

  example:

    grid [menubutton .type -menu .type.menu -textvariable temp_info(type) -font labelfont -width 10] -row 0 -column 2
    menu .type.menu

    set divided_typelist [list A [list 1 2 3 4] B [list 5 6 7 8]] 

    foreach {header types} $divided_typelist {

      .type.menu add cascade -label $header -menu [menu .type.menu.[string tolower $header]]

      foreach type $types {

        .type.menu.[string tolower $header] add radiobutton -label $type -variable temp_info(type) -value $type -command ""

      


tkt_uuid: 1734223fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: Wish crashes while scanning underlined Cyrillic menu entries
comment:
  rev 1.50 of tkWinMenu.c introduced a fix to the Tk bug #1599877, but that fix introduced the new problem:

  If the toplevel's main menu contains a Cyrillic word containing underline then wish crashes when a user presses Alt+any key in that window (i.e. triggers the code looking for accelerated menu entries). The actual crash occurs in CharUpperA (user32.dll) which is called from TkWinHandleMenuEvent (WM_MENUCHAR processing).

  The problem is that the current implementation (in my opinion) does two things wrong:
  * it assumes wParam in that case always passes a character as a byte, but it may be a wchar_t on a Unicode system.
  * it assumes an underlined character in a UTF-8 string representing the menu item label is a one-byte value.

  The actual cause of CharUpperA's failure is unclear.

  The proposed patch takes another route: it converts the character passed by Windows along with WM_MENUCHAR message to UTF-8 and then compares it case-insensitively with the underlined character from a menu item label.

  Works for both Russian and English underlined menu entries on Win XP SP2.

  Tk 8.4.15 is also affected by this problem since the fix in subject has been backported there.

  A minimal testcase:

  menu .m
  .m add cascade -label \u424\u430\u439\u43B -underline 0
  . config -menu .m

  Run with 8.4.15 or 8.5a6 then press Alt+any key to trigger a crash.


tkt_uuid: 1736223fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: None
title: tk::mac:: handlers do not throw bgerrors
comment:
  I noted the following on tcl-mac: Using 8.4.15, I've noticed that if my ::tk::mac::ShowPreferences routine throws an error, it isn't handled by bgerror; it's simply swallowed with no evidence.  It was quite puzzling until I figured out what was going on.

  So: is this expected behavior?  Do the other ::tk::mac handlers have the same behavior?  And is there any reason why errors in these routines shouldn't be handed to bgerror?

  Daniel Steffen responded: 

  all the tk::mac handlers currently use Tcl_GlobalEval() resp
  Tcl_EvalEx() and ignore the returned result, it would not be difficult
  to add error propagation via [bgerror], all that is missing is a call
  to Tcl_BackgroundError() in case of error return.
  Please file a bug to remind me to have look at this.


tkt_uuid: 1737288fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Text segfault with Modified event after delete
comment:
  8.4 text widget has problems when processing <<Modified>> event caused by delete. This segfaults once the widget gets focus (sorry, I cannot test 8.5):

  #!/usr/bin/wish8.4
  text .t
  .t insert insert x
  bind .t <<Modified>> update
  .t edit modified 0
  pack .t

  update
  after 4000
  .t delete 1.0 1.1

  Alternatively, use just the first 6 lines, click in the left halve of the window and press Backspace to get Segmentation fault as well.

  This is a minimalistic example and rather strange one, doing "update" does not make much sense. However it ilustrates likely data corruption which has other symptoms as well.

  I wanted to invoke procedure after every text change and I found that after delete and <<Modified>> event, this procedure still reports text as it was BEFORE delete (while inserting chars is fine). Example:

  proc modified {} {
    if {![.t edit modified]} {
      # invoked by itself
      return
    }
    .t edit modified 0
    puts text:[.t get 1.0 end]
  }
  text .t
  bind .t <<Modified>> modified
  pack .t

  Now type "A" in text widget, delete it and type "X". Response is:

  text:A    <-- OK
  text:A    <-- WRONG! Text is empty now!
  text:X    <-- OK

  Text widget itself looks as it should ("A" appears, disappears, "X" appears). Things also look OK when inspected outside of the event processing procedure. Just after delete, while processing <<Modified>>, data structures seem to be inconsistent, leading to slight errors or even segfaults.

  Vaclav Hanzl

  hanzl (at) noel dot feld dot cvut dot cz


tkt_uuid: 1739506fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 81. Portability
priority: 9 Immediate
foundin: obsolete: 8.5a7
resolution: Fixed
title: package require Tk fails with makefile.vc
comment:
  The Tk makefile.vc uses $(TCL_PATCHLEVEL) but never defines it.  This results in a pkgIndex.tcl that fails to load Tk.

  The attached patch corrects the problem by introspecting the tcl.h file for the correct patch level using the new functionality provided by nmakehlp.c for this purpose.

  Please review, as I intend to commit this change soon.


tkt_uuid: 1739605fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: [text see] misbehaves following widget create/populate
comment:
  [text see] adjusts the text widget to the wrong place when called immediately after a text widget is created and programmatically populated.  (Subsequent calls to [text see] produce the correct behavior--even if they immediately follow the faulty call.)

  # test script 1
  # demonstrates [text see] bug

  package require Tcl 8.5
  package require Tk 8.5

  set t [text .t -wrap none]
  set s [scrollbar .s -command [list $t yview]]
  $t configure -yscrollcommand [list $s set]
  grid $t $s -sticky nsew

  for {set i 1} {$i <= 100} {incr i} {
      $t insert end "This is line $i\n"
  }
  $t see 1.0
  raise .


tkt_uuid: 1739613fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 8
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Tk_CreateOptionTable crash due to incorrect use of TSD
comment:
  The Windows flavor of TkpButtonSetDefaults incorrectly causes the defValue for BorderWidth in the process-wide optionSpecs for buttons to be set to a thread-specific value.  When the storage for that thread is cleaned up, the next reference to that value results in a crash.

  Prolematic code:

  win/tkWinButton.c, near line 204

  for ( ; specPtr->type != TK_OPTION_END; specPtr++) {
      if (specPtr->internalOffset == Tk_Offset(TkButton, borderWidth)) {
          specPtr->defValue = tsdPtr->defWidth; /* BAD */
      }
  }

  This is a process versus thread lifetime issue due to tsdPtr->defWidth be a static buffer that will not exist after its thread exits.  I believe the fix is to make a copy of the value for use by the whole process; however, I'm not sure how the lifetime of that memory will need to be managed based on the current design.

  Stack trace:

   msvcr80d.dll!_strlen()  + 0x30 bytes
   tcl85tg.dll!Tcl_DbNewStringObj(const char * bytes=0x07f17c2c, int length=0xffffffff, const char * file=0x084a93ec, int line=0x0000010c)  Line 261 + 0xf bytesC
  >tk85tg.dll!Tk_CreateOptionTable(Tcl_Interp * interp=0x07d1d048, const Tk_OptionSpec * templatePtr=0x0849f598)  Line 268 + 0x20 bytesC
   tk85tg.dll!ButtonCreate(void * clientData=0x00000000, Tcl_Interp * interp=0x07d1d048, int objc=0x0000000a, Tcl_Obj * const * objv=0x07cf7f2c, int type=0x00000000)  Line 663 + 0x14 bytesC
   tk85tg.dll!Tk_LabelObjCmd(void * clientData=0x00000000, Tcl_Interp * interp=0x07d1d048, int objc=0x0000000a, Tcl_Obj * const * objv=0x07cf7f2c)  Line 591 + 0x17 bytesC
   tcl85tg.dll!TclEvalObjvInternal(Tcl_Interp * interp=0x07d1d048, int objc=0x0000000a, Tcl_Obj * const * objv=0x07cf7f2c, const char * command=0x00000000, int length=0x00000000, int flags=0x00000000)  Line 3620 + 0x1d bytesC
   tcl85tg.dll!TclExecuteByteCode(Tcl_Interp * interp=0x07d1d048, ByteCode * codePtr=0x07eae678)  Line 1963 + 0x1d bytesC
   tcl85tg.dll!TclObjInterpProcCore(Tcl_Interp * interp=0x07d1d048, Tcl_Obj * procNameObj=0x07dd6530, int skip=0x00000001, void (Tcl_Interp *, Tcl_Obj *)* errorProc=0x06cb3710)  Line 1607 + 0xd bytesC
   tcl85tg.dll!TclObjInterpProc(void * clientData=0x07cd9d50, Tcl_Interp * interp=0x07d1d048, int objc=0x00000002, Tcl_Obj * const * objv=0x07e72d60)  Line 1532 + 0x16 bytesC
   tcl85tg.dll!InvokeImportedCmd(void * clientData=0x07d77d30, Tcl_Interp * interp=0x07d1d048, int objc=0x00000002, Tcl_Obj * const * objv=0x07e72d60)  Line 1878 + 0x1d bytesC
   tcl85tg.dll!TclEvalObjvInternal(Tcl_Interp * interp=0x07d1d048, int objc=0x00000002, Tcl_Obj * const * objv=0x07e72d60, const char * command=0x00000000, int length=0x00000000, int flags=0x00040000)  Line 3620 + 0x1d bytesC
   tcl85tg.dll!Tcl_EvalObjv(Tcl_Interp * interp=0x07d1d048, int objc=0x00000002, Tcl_Obj * const * objv=0x07e72d60, int flags=0x00040000)  Line 3716 + 0x19 bytesC
   tcl85tg.dll!TclEvalObjEx(Tcl_Interp * interp=0x07d1d048, Tcl_Obj * objPtr=0x07dd6280, int flags=0x00040000, const CmdFrame * invoker=0x00000000, int word=0x00000000)  Line 4506 + 0x18 bytesC
   tcl85tg.dll!Tcl_EvalObjEx(Tcl_Interp * interp=0x07d1d048, Tcl_Obj * objPtr=0x07dd6280, int flags=0x00040000)  Line 4418 + 0x15 bytesC
   tcl85tg.dll!Tcl_UplevelObjCmd(void * dummy=0x00000000, Tcl_Interp * interp=0x07d1d048, int objc=0x00000001, Tcl_Obj * const * objv=0x07cf7ad4)  Line 905 + 0x14 bytesC
   tcl85tg.dll!TclEvalObjvInternal(Tcl_Interp * interp=0x07d1d048, int objc=0x00000003, Tcl_Obj * const * objv=0x07cf7acc, const char * command=0x00000000, int length=0x00000000, int flags=0x00000000)  Line 3620 + 0x1d bytesC
   tcl85tg.dll!TclExecuteByteCode(Tcl_Interp * interp=0x07d1d048, ByteCode * codePtr=0x06e07550)  Line 1963 + 0x1d bytesC
   tcl85tg.dll!TclObjInterpProcCore(Tcl_Interp * interp=0x07d1d048, Tcl_Obj * procNameObj=0x06df02a0, int skip=0x00000001, void (Tcl_Interp *, Tcl_Obj *)* errorProc=0x06cb3710)  Line 1607 + 0xd bytesC
   tcl85tg.dll!TclObjInterpProc(void * clientData=0x07948aa0, Tcl_Interp * interp=0x07d1d048, int objc=0x00000003, Tcl_Obj * const * objv=0x07cf7618)  Line 1532 + 0x16 bytesC
   tcl85tg.dll!TclEvalObjvInternal(Tcl_Interp * interp=0x07d1d048, int objc=0x00000003, Tcl_Obj * const * objv=0x07cf7618, const char * command=0x00000000, int length=0x00000000, int flags=0x00000000)  Line 3620 + 0x1d bytesC
   tcl85tg.dll!TclEvalObjvInternal(Tcl_Interp * interp=0x07d1d048, int objc=0x00000002, Tcl_Obj * const * objv=0x0723fd2c, const char * command=0x00000000, int length=0x00000000, int flags=0x00020000)  Line 3547 + 0x1b bytesC
   tcl85tg.dll!Tcl_EvalObjv(Tcl_Interp * interp=0x07d1d048, int objc=0x00000002, Tcl_Obj * const * objv=0x0723fd2c, int flags=0x00020000)  Line 3716 + 0x19 bytesC
   tcl85tg.dll!TclDefaultBgErrorHandlerObjCmd(void * dummy=0x00000000, Tcl_Interp * interp=0x07d1d048, int objc=0x00000003, Tcl_Obj * const * objv=0x07dd5e18)  Line 340 + 0x14 bytesC
   tcl85tg.dll!TclEvalObjvInternal(Tcl_Interp * interp=0x07d1d048, int objc=0x00000003, Tcl_Obj * const * objv=0x07dd5e18, const char * command=0x00000000, int length=0x00000000, int flags=0x00020000)  Line 3620 + 0x1d bytesC
   tcl85tg.dll!Tcl_EvalObjv(Tcl_Interp * interp=0x07d1d048, int objc=0x00000003, Tcl_Obj * const * objv=0x07dd5e18, int flags=0x00020000)  Line 3716 + 0x19 bytesC
   tcl85tg.dll!HandleBgErrors(void * clientData=0x07de2f18)  Line 218 + 0x19 bytesC
   tcl85tg.dll!TclServiceIdle()  Line 738 + 0x10 bytesC
   tcl85tg.dll!Tcl_DoOneEvent(int flags=0xffffffff)  Line 991 + 0x5 bytesC


tkt_uuid: 1741072fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 25. Built-in Bitmaps
priority: 5 Medium
foundin: None
resolution: None
title: request for script level introspection for names of bitmaps
comment:
  It would be useful if Tk provided script level introspection to retrieve the names of the bitmaps that Tk knows at any particular time.  Right now, a developer has to locate the Tk_GetBitmap man page and add some code that hard codes a list, and has to keep track of updates to that man page for new bitmaps.

  It would be useful if Tk provided commands for retrieving any resource lists that it knows "intrinsically" (colors, bitmaps, etc.)


tkt_uuid: 1743786fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: Fixed
title: tk_getOpenFile returns garbage for "Cancel"
comment:
  Starting with 8.4.15 tk_getOpenFile returns garbage like "after#15"
  when the user presses the Cancel button in the file dialog.
  It is supposed to return ""...

  This happens in my application but I could not reproduce this
  with wish.

  Digging through the source of NavServicesGetFile() in tkMacOSXDialog.c
  I think I found the source of the problem:
  theResult = Tcl_NewObj();
  , something like:
  Tcl_SetStringObj(theResult, "", -1);
  , and
  Tcl_SetObjResult(interp, theResult);
  never seem to take place, when the result of the dialog is not
  noErr.
  However, for the Cancel button case err == userCanceledErr...
  So, I added the upper three lines to the branch where the
  userCanceledErr case is handled. This fixed it for me:
  -snip-
      } else if (err == userCanceledErr) {
        theResult = Tcl_NewObj();
        Tcl_SetStringObj(theResult, "", -1);
  Tcl_SetObjResult(interp, theResult);
  result = TCL_OK;
      }
  -snap-

  best regards,
  Randolf,
  -- 
  http://www.ayam3d.org/    The best things in life are free!


tkt_uuid: 1747794fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: None
title: Menu posts outside screen
comment:
  with

  set ::tk::mac::useCustomMDEF 1

  a menubutton posts its menu outside the right screen border if the menubutton is very close to the right screen border.

  with

  set ::tk::mac::useCustomMDEF 0

  the menu will always be inside the screen border.


  kind regards,
  uwe


tkt_uuid: 1749251fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: 8.5 doesn't build correctly on netbsd when using XFT
comment:
  When building Tk on netbsd (cvs head 07/06/2007) using xft (the default) the building process fails at:

  rm -f libtk85.so
  ld -Bshareable -x -o libtk85.so 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 tkStyle.o tkUndo.o tkUtil.o tkVisual.o tkWindow.o tkButton.o tkEntry.o tkFrame.o tkListbox.o tkMenu.o tkMenubutton.o tkMenuDraw.o tkMessage.o tkPanedWindow.o tkScale.o tkScrollbar.o tkCanvas.o tkCanvArc.o tkCanvBmap.o tkCanvImg.o tkCanvLine.o tkCanvPoly.o tkCanvPs.o tkCanvText.o tkCanvUtil.o tkCanvWind.o tkRectOval.o tkTrig.o tkImage.o tkImgBmap.o tkImgGIF.o tkImgPPM.o tkImgPhoto.o tkText.o tkTextBTree.o tkTextDisp.o tkTextImage.o tkTextIndex.o tkTextMark.o tkTextTag.o tkTextWind.o tkStubInit.o tkStubLib.o ttkBlink.o ttkButton.o ttkCache.o ttkClamTheme.o ttkClassicTheme.o ttkDefaultTheme.o ttkElements.o ttkEntry.o ttkFrame.o ttkImage.o ttkInit.o ttkLabel.o ttkLayout.o ttkManager.o ttkNotebook.o ttkPanedwindow.o ttkProgress.o ttkScale.o ttkScrollbar.o ttkScroll.o ttkSeparator.o ttkSquare.o ttkState.o ttkTagSet.o ttkTheme.o ttkTrace.o ttkTrack.o ttkTreeview.o ttkWidget.o ttkStubInit.o ttkStubLib.o tkUnix.o tkUnix3d.o tkUnixButton.o tkUnixColor.o tkUnixConfig.o tkUnixCursor.o tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o tkUnixFocus.o  tkUnixRFont.o tkUnixInit.o tkUnixKey.o tkUnixMenu.o tkUnixMenubu.o tkUnixScale.o tkUnixScrlbr.o tkUnixSelect.o tkUnixSend.o tkUnixWm.o tkUnixXId.o  -L/usr/X11R6/lib -lX11 -lXss -lXext -Wl,-rpath,/usr/X11R6/lib -L/usr/X11R6/lib -lXft -L/usr/X11R6/lib -lfreetype -L/usr/X11R6/lib -lfontconfig -L/usr/X11R6/lib -lXrender   -lm -L/home/emiliano/programas/lib -ltclstub85   -rpath /home/emiliano/programas/lib:/usr/X11R6/lib
  ld: unrecognized option '-Wl,-rpath,/usr/X11R6/lib'
  ld: use the --help option for usage information
  gmake: *** [libtk85.so] Error 1

  The problem is in the use of 'ld' to link. This patch address the issue and the build process completes successfully.


  --- Makefile.orig       2007-07-06 13:50:57.000000000 -0300
  +++ Makefile    2007-07-06 13:50:06.000000000 -0300
  @@ -568,7 +568,7 @@
   # a shared library or non-shared library for Tk.
   ${LIB_FILE}: ${OBJS} ${STUB_LIB_FILE} 
          rm -f $@
  -       ${SHLIB_LD} -o $@ ${OBJS} ${SHLIB_LD_LIBS} ${TCL_SHLIB_LD_EXTRAS} ${TK_SHLIB_LD_EXTRAS} ${LD_SEARCH_FLAGS}
  +       ${CC} -shared -o $@ ${OBJS} ${SHLIB_LD_LIBS} ${TCL_SHLIB_LD_EXTRAS} ${TK_SHLIB_LD_EXTRAS} ${CC_SEARCH_FLAGS}
   
   ${STUB_LIB_FILE}: ${STUB_LIB_OBJS}
          rm -f $@


tkt_uuid: 1751560fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 86. Test Tools
priority: 8
foundin: obsolete: 8.4.15
resolution: None
title: make test failures
comment:
  On a Sun Solaris 9 system running under CDE or Gnome 2.0, when "make test" is run it hangs indefinitely on the window.test, requiring that it be killed manually.  This problem has been confirmed by other users including Larry Virden.

  I also see two other failures:

  One is the font test which displays a message that this is expected to fail on some UNIX systems.  It would be nice if there were a check for the offending font on the system so that this test could be skipped if it were not applicable.

  The unixWm.test also fails as follows:
  --------------------------------------------------
  unixWm.test

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

          wm withdraw .t
          sleep 200
          wm geom .t $geom
          update
          wm deiconify .t
          wm geom .t

  ---- Result was:
  100x150+0+26
  ---- Result should have been (exact matching):
  100x150+0+0
  ==== unixWm-4.3 FAILED 
  --------------------------------------------------

  This is almost certainly due to the fact that I have a Gnome toolbar running across the top of my screen which causes the offending 26 pixel offset.  This test should be modified to check for this condition and adjust accordingly.

  My philosophy is that a test suite needs to run 100% clean and report no errors on all target systems if it is to be truly useful.  I hope this report helps in meeting that target.

  Regards,
  -- 
  Jeffery Small


tkt_uuid: 1752151fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 6
foundin: obsolete: 8.4.14
resolution: Accepted
title: ::tk::mac::ShowPreferences documentation
comment:
  A documentation bug...

  Updated info on the consequences of ::tk::mac::ShowPreferences needs to be added to the Apple Menu section of the Menu manual page -- ie, that this command is now used instead of a menu item to handle the 'Preferences' entry in the Apple Menu on the Mac OS X platform.

  This is especially needed since this is apparently a new change in 8.4.14, won't appear in older manual pages, is bound to catch a lot of people out and cause many similar queries unless mentioned explicitly.

  See: http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/8f9880f795ce40a6/8d1671c3079d857b


tkt_uuid: 1753609fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: menu separator background
comment:
  with
     set ::tk::mac::useCustomMDEF 1
  a menu separator uses a different background than the menu items.

  This is barely noticable and only cosmetic, but still a nuicance.

  kind regards,
  uwe


tkt_uuid: 1753615fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: option symbol in menu acceletator
comment:
  with
     set ::tk::mac::useCustomMDEF 1
  the option symbol of a menu acceleartor uses a different font than the original mac option symbol.

  it would be nice if this was consisten with the original mac menus.

  kind regards,
  uwe


tkt_uuid: 1753929fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Wont Fix
title: menu without entries
comment:
  with
  set ::tk::mac::useCustomMDEF 0
  it is possible to create menus without entries in the mac menu bar.

  this can be used to display some application state (or a digital clock...) in the menubar.

  with
  set ::tk::mac::useCustomMDEF 1
  this is no longer possible.

  please re-enable the original behaviour.

  kind regards,
  uwe


tkt_uuid: 1754048fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: Extra options for tags
comment:
  As part of Tklib's ntext package, I have written bindings for Tk's text widget that indent wrapped display lines (other than the first of each logical line) using -lmargin2.  The purpose is to make all display lines observe the same leading whitespace as the first, giving a neater display of text.

  New options for text tags would greatly help the visual interpretation of text displayed in this way.  The options I would like are:

    -lmargin2color color
    specifies the background color to use (instead of "-background color") in regions that cannot contain characters because they are indented by -lmargin2

    -lmargin2stipple bitmap
    specifies a bitmap that is used as a stipple pattern for the background (instead of "-bgstipple bitmap") in regions that cannot contain characters because they are indented by -lmargin2

  Other users might want corresponding tag options for -lmargin1 and -rmargin; for my purposes, I only need these tag options for -lmargin2.

  The requested features are widely used in text editors (e.g. see the attached image of KDE's Kate), and I cannot find any way to implement them with the text widget's existing feature set.


tkt_uuid: 1754051fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 18. [text]
priority: 8
foundin: None
resolution: None
title: Ignore multiple whitespace at end of word-wrapped line
comment:
  In '-wrap word' mode, ignore multiple whitespace at the right of display lines - do not wrap it round to the start of the next display line.

  At the moment the excess is ignored only if it will fit at the end of the display line.

  This feature could be implemented by bindings, but it would be more appropriate if it were part of the widget's internal word-wrap algorithm.


tkt_uuid: 1755313fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: Big difference in speed between x and y scrolling in text wi
comment:
  The y scrolling is significantly slower than the x scrolling for a text widget filled with tagged text.

  The attached script displays a text widget with equal width and height. The text inside is arranged so that a given amount of scrolling in x and y shows the same amount of characters, tags, and tagged characters.

  Output: time needed to scroll 100% of the total width/height by 10% steps.

  Some results:

  Tcl/Tk 8.4.15 - Mac OS X 10.4.10 - G4 1.2 GHz
      X scroll :  3 516 756 microseconds per iteration
      Y scroll : 42 130 794 microseconds per iteration

  Tcl/Tk 8.4.14 - Linux 2.6.9 - AMD Opteron
      X scroll :    187 251 microseconds per iteration
      Y scroll : 15 521 640 microseconds per tieration

  Tcl/Tk 8.5.0a6 - Linux 2.6.9 - AMD Opteron
      X scroll :    194 166 microseconds per iteration
      Y scroll : 16 266 219 microseconds per tieration

  Tcl/Tk 8.4.14 - Windows XP SP2 - P4
      X scroll :  1 253 936 microseconds per iteration
      Y scroll : 21 507 107 microseconds per iteration 


tkt_uuid: 1759972fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: New tag option -selectforeground
comment:
  Existing tag options include

  -background color
  -foreground color
  -bgstipple bitmap
  -fgstipple bitmap

  To assist with syntax highlighting I would like this tag option:
  -selectforeground color

  For completeness these options could also be considered:
  -selectbackground color
  -selectbgstipple bitmap
  -selectfgstipple bitmap

  Widget Configuration
  Different colors are permitted for -foreground and -selectforeground in the widget configuration.  Often the -foreground and -selectbackground colors are dark, and the -selectforeground color is white: the text color is inverted when text is selected.

  Tag Configuration
  Tag -foreground colors are widely used, e.g. for syntax highlighting, and it would aid readability when using a light -background and a dark -selectbackground (or vice versa) if the text color could be changed when it is selected.


tkt_uuid: 1761327fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: Duplicate
title: Aqua: cascade menus in menubuttons don't post
comment:
  using OS X Aqua 8.4.15:


  cascade menus on menus attached to menubuttons don't post

  for example:

  toplevel .t
  grid [menubutton .t.m -menu .t.m.menu -width 15] -row 0 -column 0
  menu .t.m.menu
  .t.m.menu add radiobutton -label 1
  .t.m.menu add cascade -label 2 -menu .t.m.menu.m1
  menu .t.m.menu.m1
  .t.m.menu.m1 add radiobutton -label a
  .t.m.menu.m1 add radiobutton -label b



  the cascade menu under 2 doesn't post.

  this appears to be new since 8.4.13, haven't tested 8.4.14


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

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

  I have only tested this in OSX Aqua.


tkt_uuid: 1771594fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: icursor @x,y fails for negative scrollregions
comment:
  The normal method of locating where a button click  happens on a canvas TEXT item would be:

  set cx [.c canvasx $x]
  set cy [.c canvasy $y]

  set id [.c find closest $cx $cy]
  .c focus $id
  .c icursor $id @$cx,$cy

  If however the scrollregion is configured as:
  .c configure -scrollregion {0 -100 600 800}

  Then to position the ibeam in the text widget would  require:

  .c icursor $id @$cx,[expr {$cy+100}]

  That is: If the x1 or y1 coordinate is negative the indexing is wrong by that ammount.

  This bug may affect all canvas items as each item type has its own index procedure.

  Verified on tk 8.4 and 8.5a6


tkt_uuid: 1771916fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: None
title: Bad geometry reported while executing <Unmap> event
comment:
  On MacOS X 10.3.9 only! (this bug is NOT seen on MacOS X 10.4 and I have not tested for it on any other platform):

  the position component of geometry for a toplevel is reliably wrong while executing code bound to the <Unmap> event. The position is always -0+-22 instead of the correct value. This causes serious problems with code that allows the user to save and restore toplevel positions.

  This does not show up in the root window (".") unless you move it to the edge of the screen or something like that. But it reliably shows up from the beginning for another toplevel. Thus the following sample script...

  To use the sample script:
  - Run it
  - Minimize "tl" using the yellow button
  - Observe that the printed position is +0+-22 (bad)
  - Restore "tl" and move it and minimize it; the reported position is always bad

  Advanced test:
  - Minimize the root window using the yellow button
  - Observe that the printed position is (probably?) correct
  - Restore the root window, move it to various places, minimize and restore. If you move it to the left and/or top edge (I think) you may see the geometry go bad and once it is bad it seems to stay bad

  Any possible workaround would be appreciated.

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

  toplevel .tl
  bind . <Unmap> {puts ". geometry [winfo geometry .]"}
  bind .tl <Unmap> {puts ". geometry [winfo geometry .]"}


tkt_uuid: 1774593fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 9 Immediate
foundin: obsolete: 8.5.0
resolution: Fixed
title: Transparent items bindings undocumented (but very useful)
comment:
  Some canvas items can be invisible (using color "") and yet fire scripts bound to <Enter>, <Leave> etc. This is very useful but undocumented and therefore programmers have no guarantee that related features will stay as they are.

  For example, to create active rectangle area, several solutions come to mind and only experiments can determine  which one works and which does not:

  - rectangle item
  - very thick line
  - polygon

  (polygon and thick line work, while rectangle item reacts only by its outline)

  Fortunately, TIP46 withdrawal notice might serve as a precedens case, indicating that current invisible items behavior is intentional and will be kept as it is, however documenting it in the canvas man page would be much better.


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

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

  <double click in the widget>

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

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

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

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


tkt_uuid: 1778168fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: None
resolution: None
title: spinbox -values shouldn't override -textvar
comment:
  This was originally submitted as ActiveTcl Bug 71910:

  When I set a "-values" list and a "-textvariable" for a spinbox, the first item in the -values list replaces the -textvariable I specified. I received this reply to the bug report:

  ------- Comments from JeffH@activestate.com  2007-08-20 11:30
  This is by design, that when setting both -textvar and -values, the -values
  will override whatever -textvar specified.  Please refile as an RFE at
  tcl.sourceforge.net to track with the core bug db.

  I think the -textvariable should take precedence over the first item in the -values list, just as it does over a "-from" setting. My example: I want spinboxes to show the default time signature for a musical composition, 4/4, with the -values for the denominator of the time signature being 2 (half note), 4 (quarter note), 8 (eighth note), and 16 (sixteenth note). The user shouldn't have to change "4/2" time to "4/4" every time, and it looks too weird to have the -values order be "4 2 8 16."

  Thanks,

  David McClamrock
  <mcclamrock@locl.net>


tkt_uuid: 1778563fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.5a7
resolution: Fixed
title: Document the UTF8_STRING selection type
comment:
  The is currently nothing in the selection manual page about the UTF8_STRING type used on unix to handle selection of non-ascii string data.


tkt_uuid: 1779265fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 8
foundin: obsolete: 8.4.15
resolution: None
title: GUI freezes in some laptops running Windows
comment:
  There is a strange problem that only occurs in some notebooks running Windows. 
  I have a Tcl/Tk application that executes another one using 'open |<command> r+', the pipe returned by open is used to communicate to the standard input/output of the new process. 
  The second process works fine until any key is pressed when any of its windows owns the focus, then the GUI freezes. But if something is written in its 'stdin' it wakes up, then the key event is received, and everything works again. After that no more key presses causes a freeze.

  This pair of Tcl files recreates the error: 
  ########################################## 
  ## File run-hello.tcl 
  proc read-pipe {pipe} {
      if {![eof $pipe]} {
          puts [gets $pipe]
      } else {
          close $pipe
      }
  }

  set pipe [open "| tclsh.exe hello.tcl" r+]
  fconfigure $pipe -buffering line
  fileevent $pipe readable [list read-pipe $pipe]

  package require Tk
  button .b -text {Send -wake up-} -command [list puts $pipe {wake up}]
  pack .b
  ########################################## 

  ########################################## 
  ## File hello.tcl 
  proc read-pipe {pipe} {
      if {![eof $pipe]} {
          puts [gets $pipe]
      } else {
          close $pipe
      }
  }
  fileevent stdin readable {read-pipe stdin}

  package require Tk
  button .b -text Hello -command {puts Hello!}
  pack .b
  ########################################## 

  This code seems to be correct and it works fine in Unix and most Windows machines, it only hangs in some laptops running Windows. 

  The laptop were I detected the bug, is a Compaq nc6400. But I know it happened also in an IBM Thinkpad.
  I have tested it with some versions of tcl, and the problem has always appeared:
  ActiveTcl 8.4.7
  ActiveTcl 8.4.15
  dqkit     8.4.13
  tclkit    8.5.a6

  OS version: Windows XP Professional SP2
  Other info:
  env(PROCESSOR_ARCHITECTURE) = x86
  env(PROCESSOR_IDENTIFIER)   = x86 Family 6 Model 14 Stepping 8, GenuineIntel
  env(PROCESSOR_LEVEL)        = 6
  env(PROCESSOR_REVISION)     = 0e08
  tcl_platform(byteOrder) = littleEndian
  tcl_platform(machine)   = intel
  tcl_platform(os)        = Windows NT
  tcl_platform(osVersion) = 5.1
  tcl_platform(platform)  = windows
  tcl_platform(wordSize)  = 4


tkt_uuid: 1782105fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 9 Immediate
foundin: obsolete: 8.4.15
resolution: Fixed
title: tk_chooseColor returns garbage
comment:
  Similar to bug 1743786 also tk_chooseColor returns garbage,
  in this case for the "Ok" _and_ the "Cancel" button case.
  I get return values like "after#25" for the Cancel button
  and "after#25#fefefe" for the "Ok" button.
  As in 1743786 this shows up in my application but is not
  reproducible with plain wish.

  Maybe this is, because in tkMacOSXDialog.c:Tk_ChooseColorObjCmd()
  only Tcl_AppendResult() is used for "Ok", and no change to the
  result is attempted for "Cancel"?

  best regards,
  Randolf,
  -- 
  http://www.ayam3d.org/    Ayam, taming the RenderMan interface.


tkt_uuid: 1783474fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 3 Low
foundin: obsolete: 8.4.15
resolution: Wont Fix
title: Loading font when creating a widget
comment:
  Current policy for obligatory loading a default font first (when creating a widget) - and only then checking the option's "-font xyz" ev. existence - causes a long delay in case of unix-like systems, most probably because of the client/server architecture of X-Window.

  It can be easily checked using following code:

  set ii 0
  set report [time {
    label .label$ii -text "label #$ii" -font "Helvetica 10"
    pack .label$ii
    puts $ii
    incr ii
  } 200]

  ...when the "-font" option will be removed, the construction of such window will be done about 25 times(!) faster, than while using that option. The 
  details were cleared in the discussion thread available at: http://tinyurl.com/ytjs3u


tkt_uuid: 1785511fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 8
foundin: obsolete: 8.4.15
resolution: None
title: "unknown display passed to Tk_PreserveColormap"
comment:
  This error is hard to reproduce. The number of images
  is not critical. The reuse of the image names when recreating the images may be.

  Basic method.

     create a canvas widget
     create three gif images with "image create photo"
     create three image items on the canvas.

     delete the three images
     re-source the script above.
     do not call update or update idletasks between
     image deletion and re-creation.

  The panic appears to happen at the time the images are recreated and before they are added to the canvas although this cannot be confirmed.
     
  It is likely that the cause of the error is the fact that the original images are deleted via an idle callback which has not fired by the time they are re-created and the new images that are recreated using the same names are being deleted by the idle call back which now fires for the three original images.


tkt_uuid: 1788019fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 7 High
foundin: obsolete: 8.5a7
resolution: Fixed
title: tkTest.c compiler warning
comment:
  /home/dgp/release/tk8.5b1/unix/../generic/tkTest.c: In function ‘TestpropCmd’:
  /home/dgp/release/tk8.5b1/unix/../generic/tkTest.c:1989: warning: dereferencing type-punned pointer will break strict-aliasing rules


tkt_uuid: 1789055fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 34. [tk_chooseColor]
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: Invalid
title: tk_chooseColor returns None#(color)
comment:
  Using Aqua Tcl/Tk 8.4.15 I am seeing tk_chooseColor return "None#xxxxxx" (where #xxxxxx is a valid color) after pressing OK, or "None" after pressing Cancel. This may be related to PR 1782105. But I still see it in 8.4.16rc0, which was released after that PR was closed.

  The problem is that this does not show up in wish, but only when running my application. I have not been able to track down what starts it, but:
  - It always starts at the same point in my (complicated) code. So far efforts to track down the trigger (and thus simplify the code) have been in vain.
  - once it begins, it always happens

  I am happy to work harder at getting a small application and can easily supply an application that shows the bug (and contains source).


tkt_uuid: 1789752fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Accepted
title: background exception handling
comment:
  Here's a patch that transforms
  most Tcl_BackgroundError() calls
  in Tk into TclBackgroundException()
  calls when that appears more
  appropriate.

  Leaving it to maintainer judgment
  whether the slightly more correct
  result is worth greater use of
  Tcl internal interfaces, or whether
  this should wait until something
  in Tcl's public interface arrives.


tkt_uuid: 1789819fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: None
title: Panic in [wm stackorder]
comment:
  Reported on the Tcl'ers chat (GPS and stever both replicated):

  Running the Tk test suite under the Whim window manager causes a panic in [wm stackorder]

  Problem narrowed down to test wm-stackorder-5.2:

  ++++ wm-stackorder-4.4 PASSED
  ++++ wm-stackorder-5.1 PASSED
  num matched toplevel windows does not equal num children
  /bin/sh: line 1: 20192 Aborted


tkt_uuid: 1790947fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 3 Low
foundin: obsolete: 8.4.15
resolution: Wont Fix
title: text widget man page can't break lines
comment:
  Viewing the text.3tk man page generates 13 warnings about lines that can't be adjusted or broken:

  $ man ./text.n > /dev/null
  Reformatting text(3tk), please wait...
  ./text.n:951: warning [p 13, 9.0i]: cannot adjust line
  ./text.n:957: warning [p 13, 10.3i]: cannot adjust line
  ./text.n:963: warning [p 14, 0.0i]: cannot adjust line
  ./text.n:966: warning [p 14, 0.7i]: cannot adjust line
  ./text.n:970: warning [p 14, 1.5i]: cannot adjust line
  ./text.n:1727: warning [p 24, 4.3i]: can't break line

  The warnings appear to be emitted from nroff, so it might actually be an nroff problem:

  $ soelim text.n > soelim.out
  $ iconv -c -f UTF-8 -t ISO-8859-1 soelim.out > iconv.out
  $ tbl iconv.out > tbl.out
  $ nroff -mandoc -Tutf8 tbl.out > nroff.out
  ./text.n:951: warning [p 13, 9.0i]: cannot adjust line
  ./text.n:957: warning [p 13, 10.3i]: cannot adjust line
  ./text.n:963: warning [p 14, 0.0i]: cannot adjust line
  ./text.n:966: warning [p 14, 0.7i]: cannot adjust line
  ./text.n:970: warning [p 14, 1.5i]: cannot adjust line
  ./text.n:1727: warning [p 24, 4.3i]: can't break line

  I've also found that removing the .VS macros calls (and their corresponding .VE macro calls afterward) silences the warnings.

  I've seen this in 8.4.14, 8.4.15, 8.5a5, and 8.5a6, The warnings appear at different line numbers as the text of the man page changes from release to release.


tkt_uuid: 1791052fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5a6
resolution: Fixed
title: NULL pointer dereference in LayoutDLine
comment:
  There's a quite reproducible bug in the Text widget that occurs in Tkabber free XMPP client (http://tkabber.jabber.ru).

  Unfortunately I have not yet managed to successfully extract the testcase, so here's some background:

  Tkabber uses Text widgets to render chats, and there embedded images are used to render emoticons (smileys) and mathematical formulae (via the LaTeX plugin). The bug occurs when a window representing a chat session (implemented with the Text widget) is opened and is being initially populated either by chat history or by the message sent to the user that triggered creation of such a window. Then iff the text in that Text widget is happened to contain an embedded image in the last chat message, the bug is almost always triggered.

  I have managed to narrow the bug: it was most probably introduced with the implementation of TIP #256 since version of 04-Oct-2005 works and one of 11-Oct-2005 crashes.

  This bug occurs on both Windows and X Window-based systems. 8.4.15 (from ActiveState) is also affected (probably, the implementation has been backported there).

  I can propose the occurence of this bug does somehow relate to the fact that the Text image in subject ends up being packed in several [grid]s and BWidget's ScrolledWindow which may affect size of the widget in the process of creation of the whole window hierarchy for a chat session.

  Here's the stack trace (MS VC6):

  LayoutDLine(TkText * 0x0290bc48, const TkTextIndex * 0x0026fc68) line 1503 + 22 bytes
  CalculateDisplayLineHeight(TkText * 0x0290bc48, const TkTextIndex * 0x0026fc68, int * 0x0026fc18, int * 0x0026fc1c) line 3429 + 13 bytes
  TkTextUpdateOneLine(TkText * 0x0290bc48, TkTextLine * 0x0290c080, int 240, TkTextIndex * 0x0026fc68, int 1) line 3595 + 21 bytes
  TkTextUpdateLineMetrics(TkText * 0x0290bc48, int 0, int 0, int 256) line 2969 + 29 bytes
  AsyncUpdateLineMetrics(void * 0x0290bc48) line 2789 + 28 bytes
  TCL85G! 100ca4a8()
  TCL85G! 100a776f()
  TCL85G! 100a7b72()
  Tk_MainLoop() line 2143 + 15 bytes
  Tk_MainEx(int 3, char * * 0x00b0263c, int (Tcl_Interp *)* 0x00401005 _Tcl_AppInit, Tcl_Interp * 0x00b05070) line 308
  WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00292332, int 1) line 129 + 37 bytes
  WinMainCRTStartup() line 330 + 54 bytes
  KERNEL32! 7c816d4f()

  The actual place of dereference is line 1503 at generic/tkTextDisp.c:

      if (breakChunkPtr == NULL) {
  /*
   * This code makes sure that we don't accidentally display chunks with
   * no characters at the end of the line (such as the insertion
   * cursor). These chunks belong on the next line. So, throw away
   * everything after the last chunk that has characters in it.
   */

  breakChunkPtr = lastCharChunkPtr;
  breakByteOffset = breakChunkPtr->numBytes;
      }
      if ((breakChunkPtr != NULL) && ((lastChunkPtr != breakChunkPtr)
      || (breakByteOffset != lastChunkPtr->numBytes))) {
  while (1) {
      chunkPtr = breakChunkPtr->nextPtr;
      if (chunkPtr == NULL) {
  break;
      }
      FreeStyle(textPtr, chunkPtr->stylePtr);
      breakChunkPtr->nextPtr = chunkPtr->nextPtr;
  here ->    (*chunkPtr->undisplayProc)(textPtr, chunkPtr);
      ckfree((char *) chunkPtr);
  }
  if (breakByteOffset != breakChunkPtr->numBytes) {
      (*breakChunkPtr->undisplayProc)(textPtr, breakChunkPtr);
      segPtr = TkTextIndexToSeg(&breakIndex, &byteOffset);
      (*segPtr->typePtr->layoutProc)(textPtr, &breakIndex,
      segPtr, byteOffset, maxX, breakByteOffset, 0,
      wrapMode, breakChunkPtr);
  }
  lastChunkPtr = breakChunkPtr;
  wholeLine = 0;
      }

  P.S. sorry for not presenting a working testcase. If anyone in charge would like to try to run Tkabber so see the bug, feel free to contact me for support.


tkt_uuid: 1792191fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5b3
resolution: Fixed
title: Copy-paste error on manual page
comment:
  Text on "tag remove" is apparently copy-pasted from "tag add", because "If the last index2 is omitted then the single character at index1 is tagged." This information is also wrong because "ending just before index2 (the character at index2 isn't affected)." means "tag remove tagname index" is a no-op (index2 == index1).


tkt_uuid: 1792398fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 34. [tk_chooseColor]
priority: 5 Medium
foundin: obsolete: 8.4.15
resolution: Out of Date
title: alert and tk_xyv dialogs
comment:
  It's best to give you a sample app that is not working:

  proc say_hi {} { puts "HELLO" ; after 1000 say_hi }
  say_hi
  set color [tk:chooseColor]
  puts "...$color..."
  exit

  The above app will print:

  ...after#8#85f4c1...

  Notice the color element is in there, but it's prefixed by after#8. Other dialogs will do this to in some situations (same thing as above but...)

  set fname [tk_getOpenFile]

  Now, instead of choosing a file (that works right) click cancel and you'll get something like "after#18".

  Now, talking in #tcl, we were able to track down somethings. If you change the say_hi function, and do, say a list as the last command in the function, all dialogs begin to work...

  proc say_hi {} { puts "HELLO" ; after 1000 say_hi; list }
  say_hi
  set color [tk:chooseColor]
  puts "...$color..."
  exit

  That application (notice the "list" in "say_hi") will print:

  ...#85f4c1...

  Which is correct.


tkt_uuid: 1792432fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 9 Immediate
foundin: obsolete: 8.5a7
resolution: Invalid
title: --disable-shared Tcl / --enable-shared Tk
comment:
  This combination produces a working
  wish using the Tcl/Tk 8.5a6 releases.

  It produces a wish that crashes on 
  the HEAD:

  $ ./wish
  ./wish: symbol lookup error: ./wish: undefined symbol: Tcl_InitStubs

  Perhaps a consequence of the changes
  addressing 1716117 ?


tkt_uuid: 1794328fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 81. Portability
priority: 5 Medium
foundin: None
resolution: Rejected
title: Silence 64 bit type conversion warnings
comment:
  The attached patch silences the 64 bit porting warnings I get when building Tk with msvc8 for the Windows 64bit AMD64 target. On this platform size_t != long so there is quite a lot of cast truncations to be done. Tcl in general seems to use int for the size of most things.


tkt_uuid: 1794786fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: None
resolution: Duplicate
title: Modify widget state before generating <<Modified>> event
comment:
  When a widget .t generates a <<Modified>> event, it does so with the equivalent of
    event generate .t <<Modified>> -when now

  The <<Modified>> event is therefore processed immediately.  In most cases the binding to <<Modified>> will use "after idle" or "event generate" to schedule code to be executed at an appropriate later time.

  However, it is unhelpful that at the instant when <<Modified>> is generated, [.t get 1.0 end] is up to date if characters have been added to .t, but not if characters have been removed.

  Demonstration code is here:
  http://groups.google.co.uk/group/comp.lang.tcl/browse_thread/thread/ec786deb854b4194/

  It would be helpful if the widget state were always up to date when the <<Modified>> event is generated.


tkt_uuid: 1797555fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 8
foundin: obsolete: 8.4.16
resolution: None
title: DestroyMenuEntry writes into freed memory
comment:
  Our application has a couple of semi-dynamic menus that are updated (destroyed and recreated) when the user opens and closes data files.  When ever the menu is updated, I get the enclosed error that is shown by valgrind.  We're using Tcl/Tk via Python, so my next step is to come up with a Tcl-only test case, but in case I don't, here's a record of the bug (the line numbers refer to the 8.4.15 release):

  Invalid read of size 4 
     at 0x5449FA2: DestroyMenuEntry (tkMenu.c:1469)
     by 0x5584B77: Tcl_EventuallyFree (tclPreserve.c:302)
     by 0x544D548: DeleteMenuCloneEntries (tkMenu.c:3498)
     by 0x5448DC4: MenuWidgetObjCmd (tkMenu.c:813)
     by 0x5513DEB: TclEvalObjvInternal (tclBasic.c:3190)
     by 0x5514049: Tcl_EvalObjv (tclBasic.c:3306)
     by 0x484F0C5: Tkapp_Call (_tkinter.c:1314)
     by 0x810221C: PyCFunction_Call (methodobject.c:108)
     by 0x80B453E: PyEval_EvalFrame (ceval.c:3563)
     by 0x80B59D4: PyEval_EvalCodeEx (ceval.c:2736)
     by 0x80B36B5: PyEval_EvalFrame (ceval.c:3656)
     by 0x80B59D4: PyEval_EvalCodeEx (ceval.c:2736)
   Address 0x6142DF8 is 0 bytes inside a block of size 16 free'd 
     at 0x40050FF: free (vg_replace_malloc.c:233)
     by 0x5510BCB: TclpFree (tclAlloc.c:702)
     by 0x55195AC: Tcl_Free (tclCkalloc.c:1160)
     by 0x544D4CA: TkFreeMenuReferences (tkMenu.c:3460)
     by 0x5449E55: UnhookCascadeEntry (tkMenu.c:1380)
     by 0x5449F98: DestroyMenuEntry (tkMenu.c:1467)
     by 0x5584B77: Tcl_EventuallyFree (tclPreserve.c:302)
     by 0x544D548: DeleteMenuCloneEntries (tkMenu.c:3498)
     by 0x5448DC4: MenuWidgetObjCmd (tkMenu.c:813)
     by 0x5513DEB: TclEvalObjvInternal (tclBasic.c:3190)
     by 0x5514049: Tcl_EvalObjv (tclBasic.c:3306)
     by 0x484F0C5: Tkapp_Call (_tkinter.c:1314)

  Invalid write of size 4 
     at 0x5449FAC: DestroyMenuEntry (tkMenu.c:1470)
     by 0x5584B77: Tcl_EventuallyFree (tclPreserve.c:302)
     by 0x544D548: DeleteMenuCloneEntries (tkMenu.c:3498)
     by 0x5448DC4: MenuWidgetObjCmd (tkMenu.c:813)
     by 0x5513DEB: TclEvalObjvInternal (tclBasic.c:3190)
     by 0x5514049: Tcl_EvalObjv (tclBasic.c:3306)
     by 0x484F0C5: Tkapp_Call (_tkinter.c:1314)
     by 0x810221C: PyCFunction_Call (methodobject.c:108)
     by 0x80B453E: PyEval_EvalFrame (ceval.c:3563)
     by 0x80B59D4: PyEval_EvalCodeEx (ceval.c:2736)
     by 0x80B36B5: PyEval_EvalFrame (ceval.c:3656)
     by 0x80B59D4: PyEval_EvalCodeEx (ceval.c:2736)
   Address 0x6142DF8 is 0 bytes inside a block of size 16 free'd 
     at 0x40050FF: free (vg_replace_malloc.c:233)
     by 0x5510BCB: TclpFree (tclAlloc.c:702)
     by 0x55195AC: Tcl_Free (tclCkalloc.c:1160)
     by 0x544D4CA: TkFreeMenuReferences (tkMenu.c:3460)
     by 0x5449E55: UnhookCascadeEntry (tkMenu.c:1380)
     by 0x5449F98: DestroyMenuEntry (tkMenu.c:1467)
     by 0x5584B77: Tcl_EventuallyFree (tclPreserve.c:302)
     by 0x544D548: DeleteMenuCloneEntries (tkMenu.c:3498)
     by 0x5448DC4: MenuWidgetObjCmd (tkMenu.c:813)
     by 0x5513DEB: TclEvalObjvInternal (tclBasic.c:3190)
     by 0x5514049: Tcl_EvalObjv (tclBasic.c:3306)
     by 0x484F0C5: Tkapp_Call (_tkinter.c:1314)


tkt_uuid: 1799782fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5a7
resolution: Fixed
title: Manual and code disagree about <<Modified>>
comment:
  (also 8.4.15)

  man n text states "Whenever the (modified) flag changes state a <<Modified>> virtual event is generated."

  In fact, the command
      $w edit modified $value
  generates a <<Modified>> event even if it does not change the state of the flag.

  The binding to <<Modified>> is responsible for testing the flag before changing it, to prevent infinite recursion.

  It would be better if the widget did precisely what the manual says - it would be one less "gotcha".


tkt_uuid: 1799963fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5a7
resolution: Invalid
title: Document keynav package
comment:
  Context: http://groups.google.com/group/comp.lang.tcl/msg/d8be991b44b2f1c0

  Joe says that the keynav package is undocumented but supported. That situation means that documentation should be written. :-)


tkt_uuid: 1800192fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 8
foundin: None
resolution: Duplicate
title: make test: many failures
comment:
  Linux Suse-10.1 x86_64
  tk 8.5 cvs version 22 september 2007
  tcl and tk are built withouit problem
  make test succeds for tcl but may tests fail for tk

  The test hangs on the window test, I had to abort it 
  with Control-C.

  Failure also on a very simple tk script that I use for years (freezes instead onf exiting)

  I attach config.log.gz
  and the gzipped output of make test


tkt_uuid: 1800744fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: None
resolution: Accepted
title: updated en.msg for tk 8.4
comment:
  updated en.msg for tk 8.4
  + added missing "Show &Hidden Directories" and "Show &Hidden Files and Directories" messages
  + changed message: "Ok" to "OK"


tkt_uuid: 1803723fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 76. Widget Tour
priority: 5 Medium
foundin: obsolete: 8.5a7
resolution: Fixed
title: Bidi wrong in Unicode label demo on WinXP
comment:
  The Unicode label demo in ActiveTcl 8.5.0b9 (= 8.5b1)
  has on Win XP the Arabic and Hebrew reversed.

  Fix: the two places where tk windowingsystem is checked should be modified to

  if {[tk windowingsystem] in {x11 win32}} {


tkt_uuid: 1803836fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5b1
resolution: Fixed
title: global namespace pollution
comment:
  In wish 8.5b1:

  % info commands {[A-Z]*}
  WordBack WordForward

  These appear to be procs
  defined in tk/library/ttk/entry.tcl .


tkt_uuid: 1803839fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5b1
resolution: Invalid
title: original widget namespace??
comment:
  % namespace origin button
  ::button
  % namespace origin tk::button
  ::tk::button

  I would have expect one of these
  commands to be a [namespace import]
  of the other.  What am I missing?


tkt_uuid: 1803857fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 9 Immediate
foundin: obsolete: 8.5b1
resolution: Wont Fix
title: ttk::[a-z]* public?
comment:
  Is the [ttk::clickToFocus] meant
  to be public?  If so, needs docs.

  If not, convention would suggest
  we name it ttk::ClickToFocus instead.


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

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

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

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

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


tkt_uuid: 1806585fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.5b1
resolution: Invalid
title: Wish 8.5b1 fails to build on osx 10.4
comment:
  In tkMacOSXWm.c,
  kWindowUnifiedTitleAndToolbarAttribute and kWindowTexturedSquareCornersAttribute
  are not defined for build env prior 10.5.


tkt_uuid: 1806613fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5b1
resolution: Duplicate
title: text widget name with "-" causes error in tk::TextSelectTo
comment:
  Having a "-" (dash) in a text widget name causes some standard bindings to throw errors. For example, run the following code then double click on some text:

  pack [text .t-1]
  .t-1 insert 1.0 "Double click on this text"

  You will get the following error:

  bad text index "tk::anchor.t-1 - 1c"
  bad text index "tk::anchor.t-1 - 1c"
      while executing
  "$w compare $cur < $first"
      (procedure "tk::TextSelectTo" line 33)
      invoked from within
  "tk::TextSelectTo .t-1 59 13"
      (command bound to event)

  The error seems to be related to the use of a mark that looks like "tk::anchor$w". If you change ".t-1" to ".t_1" the problem goes away. 

  I don't think it's a good idea to use a mark that contains the widget name since the name may contain characters that can confuse the index expression parser.


tkt_uuid: 1809538fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5b1
resolution: Fixed
title: <<Modified>> lost before text widget mapped
comment:
  <<Modified>> event is not generated when text is changed before it is shown on screen. Example (demonstrated with 8.5b1 tclkit but also seen with 8.4 wish):

  # ./tclkit-linux-x86-8.5b1
  % package require Tk
  8.5b1

  % text .t; bind .t <<Modified>> "puts MOD"; pack .t; .t insert insert "xxx"
  % 

  Text was modified but the binding did not trigger. If the same thing is done in two pieces, it triggers as expected:

  # ./tclkit-linux-x86-8.5b1
  % package require Tk
  8.5b1

  % text .t; bind .t <<Modified>> "puts MOD"; pack .t;
  % .t insert insert "xxx"
  MOD
  % 

  One use for <<Modified>> is tracking all changes to text. To ensure continued tracking, one has to reset the modified flag (and do it with some caution, as explained in tk bug #1799782). User is likely to prepare this chain before the text is mapped onscreen. If the initial text is not empty, the bug (the one I report now) completely breaks any tracking by subverting the chain at the very start. Workaround is to do [.t edit modified 0] AFTER getting the widget onscreen.

  This bug may be related to another one, which I errorneously reported in the tk patch tracker as #1737288. Then Danckaert provided a patch - maybe that patch may also fix this issue, or at least help to understand it. Now I tested 8.5b1 and 8.5a6, thought I cannot force segfault, both versions still look broken as demonstrated by my "AAX" test described in 'patch' #1737288. So I suppose Danckaert's patch is not in 8.5b1 (he patched against 8.5a6).


tkt_uuid: 1810818fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 9 Immediate
foundin: None
resolution: Fixed
title: [wm resizeable] broken in 8.5b1 on OS X only
comment:
  If resizing for either dimension is turned off then both dimensions get turned off.

  This has been introduced after 8.4.7.

  NOTE -- the windows works fine.


tkt_uuid: 1813595fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: loop race in canvas Enter / Leave bindings
comment:
  Hmmm... Seems to me there's definately a bug in tk with the canvas Enter and Leave bindings. I've tested this on wish 8.4.1, 8.4.16 and 8.5b1.

  TkHearts-0.86 runs fine, but when i entered these two bindings (patch backs them out) - bound only against players face up cards, tcl just freezes quite unpredictably. Occasionally on startup and in a game, but often after returning from a change of focus between apps, or even from the "about" widget.

  I added two lines of debugging code that trace control into doCardUp and doCardDown. They work fine, but when the game freezes, it became apparent tcl was stuck in a Enter/Leave loop, continuously calling doCardUp and
  doCardDown (which are bound to Enter and Leave). This behaviour is the same in 8.4.1 8.4.16 and 8.5b1. I run fedora4, xorg-x11-6.8.2-31.

  Another data point - I also totally removed the ".c bind player0 <Leave>" command hoping to get around the bug...
  leaving just the Enter binding, but i ~still~ managed to get a loop race condition :<

  Thanks, Steven Atkinson, stevenaaus yahoo.com


tkt_uuid: 1813597fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: Fixed
title: Canvas co-ordinate rounding e.g. 118.0 -> 117.99999
comment:
  Hmmmm... In the latest beta (8.5b1) canvas co-ordinate rounding has changed, (and is breaking my polypuzzle program). This wasn't the case in 8.5a[5|6].  I know this is a weak point of tcl... but perhaps as it is , lots of apps will break ? Below is a simple line created on a canvas in wish8.4 and then wish8.5b1. I then retrieve the coords..  Notice that in wish8.5 the
    410.99999999999994 -> 410.9999999999999
  , but *worse*, the
    118.0 -> 117.99999999999999
  Hmmm.. This last one is nasty. The rounding behaviour in 8.4 was very well behaved, and *never* gave me horrible point nines recurring.

  Anyway, thank-you for your time.
  Steven.

  Linux 2.6.23 #1 PREEMPT Fri Oct 12 19:07:53 UTC 2007
  i686 i386 GNU/Linux, xorg-x11-6.8.2-31, glibc-2.3.5-10, Fedora 4

  ----------------------------------------------------------------
  #wish8.4
  --------
  % canvas .c
  .c
  %  .c creat line 0 0 410.99999999999994 118.0
  1
  % .c coords 1
  0.0 0.0 411.0 118.0
  ----------------------------------------------------------------
  #wish8.5b1
  --------
  %  canvas .c
  .c
  % .c creat line 0 0 410.99999999999994 118.0
  1
  % .c coords 1
  0.0 0.0 410.9999999999999 117.99999999999999
  ----------------------------------------------------------------


tkt_uuid: 1814488fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.5b2
resolution: Out of Date
title: unixWm test suite failures
comment:
  I'm building the tcl/tk cvs head (snapshot from activestate) on sparc solaris 9, using sun's c compiler. 
  I used ./configure --prefix=/projects/sprs_lwv/tcl85 --enable-shared --enable-symbols --enable-stubs --enable-64bit --enable-threads
  to build tcl and tk.

  The results of the test, which occurs consistently, are:
  unixWm.test

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

          wm withdraw .t
          sleep 200
          wm geom .t $geom
          update
          wm deiconify .t
          wm geom .t
      
  ---- Result was:
  100x150+57+80
  ---- Result should have been (exact matching):
  100x150+20+80
  ==== unixWm-4.1 FAILED
  ==== unixWm-4.3 moving window while withdrawn FAILED
  ==== Contents of test case:

          wm withdraw .t
          sleep 200
          wm geom .t $geom
          update
          wm deiconify .t
          wm geom .t
      
  ---- Result was:
  100x150+57+39
  ---- Result should have been (exact matching):
  100x150+0+0
  ==== unixWm-4.3 FAILED
  ==== unixWm-25.1 Tk_WmCmd procedure, "iconname" option FAILED
  ==== Contents of test case:

      list [catch {wm icon .t} msg] $msg

  ---- Result was:
  1 {ambiguous option "icon": must be aspect, attributes, client, colormapwindows,
   command, deiconify, focusmodel, forget, frame, geometry, grid, group, iconbitma
  p, iconify, iconmask, iconname, iconphoto, iconposition, iconwindow, manage, max
  size, minsize, overrideredirect, positionfrom, protocol, resizable, sizefrom, st
  ackorder, state, title, transient, or withdraw}
  ---- Result should have been (exact matching):
  1 {ambiguous option "icon": must be aspect, attributes, client, colormapwindows,
   command, deiconify, focusmodel, frame, geometry, grid, group, iconbitmap, iconi
  fy, iconmask, iconname, iconphoto, iconposition, iconwindow, maxsize, minsize, o
  verrideredirect, positionfrom, protocol, resizable, sizefrom, stackorder, state,
   title, transient, or withdraw}
  ==== unixWm-25.1 FAILED
  ==== unixWm-39.1 Tk_WmCmd procedure, miscellaneous FAILED
  ==== Contents of test case:

      list [catch {wm unknown .t} msg] $msg

  ---- Result was:
  1 {bad option "unknown": must be aspect, attributes, client, colormapwindows, co
  mmand, deiconify, focusmodel, forget, frame, geometry, grid, group, iconbitmap, 
  iconify, iconmask, iconname, iconphoto, iconposition, iconwindow, manage, maxsiz
  e, minsize, overrideredirect, positionfrom, protocol, resizable, sizefrom, stack
  order, state, title, transient, or withdraw}
  ---- Result should have been (exact matching):
  1 {bad option "unknown": must be aspect, attributes, client, colormapwindows, co
  mmand, deiconify, focusmodel, frame, geometry, grid, group, iconbitmap, iconify,
   iconmask, iconname, iconphoto, iconposition, iconwindow, maxsize, minsize, over
  rideredirect, positionfrom, protocol, resizable, sizefrom, stackorder, state, ti
  tle, transient, or withdraw}
  ==== unixWm-39.1 FAILED
  ==== unixWm-48.13 ParseGeometry procedure, resize causes window to move FAILED
  ==== Contents of test case:

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

  ---- Result was:
  0 0 150 300
  ---- Result should have been (exact matching):
  50 -100 150 300
  ==== unixWm-48.13 FAILED
  ==== unixWm-50.1 Tk_CoordsToWindow procedure, finding a toplevel, x-coords FAILE
  D
  ==== Contents of test case:

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

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

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

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

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

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

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

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


tkt_uuid: 1814999fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.5b1
resolution: None
title: photo data -grayscale broken
comment:
  In 8.5b1, the -grayscale option of the [photo data] command yields a dark but not-quite-black image (variation in the grayscale image can be seen by increasing the -gamma value).

  The following code works as expected in 8.4.16 but not in 8.5b1:

  package require Img
  set img1 [image create photo -file c:/myimage.jpg]
  set img2 [image create photo]
  $img2 put [$img1 data -grayscale]
  set l1 [label .l1 -image $img1]
  set l2 [label .l2 -image $img2]
  grid $l1 $l2


tkt_uuid: 1815161fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5b1
resolution: None
title: .text count -ypixels wrong until widget is managed
comment:
  Doing [.text count -update -ypixels 1.0 end] returns incorrect results until the widget is first managed by a geometry manager.

  Here's the result of an interactive session:

  (tmp) 49 % text .t -width 20 -height 4
  .t
  (tmp) 50 % .t insert end "hello, world\n"
  (tmp) 51 % .t count -update -ypixels 1.0 end
  169
  (tmp) 52 % pack .t
  (tmp) 53 % .t count -update -ypixels 1.0 end
  26

  Even with an intervening "update" between lines 50 and 51, the result is the same.

  There's no mention in the man pages that the widget must first be managed by a geometry manager before the count command will work. To the contrary, it implies that -update guarantees the value will be correct. 


tkt_uuid: 1815246fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: text broken but canvas ok
comment:
  While using arabic characters I found a strange behaviour of tcl/tk. The canvas widget and the text widget should give the same display when both are given the same text, but the following two snippets show
  a difference.
  The canvas widget works as expected and displays the character \uFEA0 with a diacritic sign \u0651 above it:

     font create titusFont -family "TITUS Cyberbit Basic" -size 48
     canvas .c -width 500 -height 500
     pack .c
     .c create text 300 300 -font titusFont -text "\u0651\uFEA0"


  Trying the same with a text widget distorts the display. The base sign  \uFEA0 renders fine but the diacritic \u0651 is reduced to only one pixel width:

     font create titusFont -family "TITUS Cyberbit Basic" -size 48
     text .t -font titusFont -width 20 -height 3
     pack .t
     .t insert end  "\u0651\uFEA0"

  Is this an error of TK or am I doing something wrong? I get this strange behaviour with tcl/tk version 8.4.11, 8.4.14, and 8.5a3under linux with X11R6 version 6.8.2.


tkt_uuid: 1816252fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 6
foundin: obsolete: 8.5b1
resolution: Fixed
title: wm transient does not work
comment:
  The [wm transient] command does not make the window a transient on the ActiveState build of 8.5.

  Note -- this works with the 8.4 build that comes with OS X.

  See attached file for an example.


tkt_uuid: 1816253fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 6
foundin: obsolete: 8.5b1
resolution: Works For Me
title: tkwait visibility does not work
comment:
  The [tkwait visibility] never returns in the ActiveState 8.5 build.

  Note -- this worked in the 8.4 that ships with OS X.


tkt_uuid: 1816826fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 7 High
foundin: obsolete: 8.4.16
resolution: Works For Me
title: focus bug during window activation (Aqua)
comment:
  To produce the bug:
  toplevel .t
  pack [text .t.t1]
  toplevel .t2

  1 click into .t2
  2 Minimize .t  with the yellow button.
  3. when you deiconify the minimized window, the text box has no cursor, and also has no focus ring around it. It responds to button events but doesn't set a cursor.
  4. If you click into .t2, then back, the text box is activated again, has a cursor and a focus ring.

  if the console window is the next window down in the stack, so that it gets focus on minimizing, the bug doesn't happen.


tkt_uuid: 1818082fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: None
title: saving Canvas area as PNG/BMP/GIF via the Tk_Photo format
comment:
  I would like to submit a patch that makes the Canvas object capable of exporting not only to Postscript but also to the Tk_Photo format. Using the Tk_Photo format a user will then be able to export canvas images directly to many other different formats and not just Postscript.

  Exporting to Postscript is pretty much only usefull on Unix systems. If you work under Windows it can be a bit troublesome to convert Postscript files to the native formats... especially if you want to do this in the background in runtime...

  I submitted this idea as a patch a few years ago, but it seams  to have gotten 'buried'. It seems the Canvas object still only exports to Postscript, so I think the patch still fills a 'hole'. Hobbs gladly greeted the suggestion back then so I (modestly) imagine that it will still be gladly accepted...

  ( I submitted the patch as a part of my original feature request: '[923890] saving canvas area as PNG/BMP/GIF')

  This patch modifies the file 'generic/tkCanvas.c' and adds a the test-example 'tests/canvGetImgPhoto.tcl'
  I tested this patch on Tcl8.5b1/Tk8.5b1. Compiles and works fine.


tkt_uuid: 1818441fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 9 Immediate
foundin: obsolete: 8.5b2
resolution: Fixed
title: combobox wrong in detached window
comment:
  Run the widget demo. Run the toolbar demo within it. Tear off the toolbar. Now try to use the combobox's drop-down list. Observe the fact that it is now clipped by the toplevel (or is that the combobox?) Kill the toolbar so that it is re-docked. Observe the fact that the drop-down list is still clipped.

  This Is Not Good.


tkt_uuid: 1818491fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 51. [place]
priority: 9 Immediate
foundin: obsolete: 8.4.16
resolution: Fixed
title: Placer geometry manager crash, and patch
comment:
  When a Tk geometry manager reconfigures its
  slaves, almost anything can happen via event
  bindings, including deleting the manager widget or
  slaves.  The Tk pack and grid managers carefully
  handle this, through a combination of
  Tcl_Preserve/Tcl_Release and an abort flag.  The
  corresponding code is missing from the place
  manager.

  With Tcl/Tk 8.4.15 I was seeing crashes while using
  place in mega-widget construction, in complex
  timing-relating circumstances.  I have since
  produced a (very) contrived simple example, in
  placer.tcl.  Run it with wish.  Using Tcl/Tk
  8.4.15 resizing the main window crashes wish every
  time on my Solaris unix build, and on a Windows-XP
  single-threaded build.  Memory corruption - so
  your mileage may vary for different builds.

  I have applied exactly the same protection method
  as used in grid and pack to the placer.  This
  solve the problem in placer.tcl, and in my real
  application.  The Tcl/Tk 8.4 updated code applied
  to CVS 1.13.2.1 is in tkPlace.c.84.  I have also
  updated the Tcl/Tk 8.5 code from CVS 1.22, in
  tkPlace.c.85.


tkt_uuid: 1820344fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 02. Appearance
priority: 8
foundin: None
resolution: Fixed
title: New Classic look for 8.5
comment:
  Attached is a patch with a reverse focus from the tklib as::style work.  It changes the defaults (X11 only in this first patch - maybe some Aqua and Win32 changes needed too), and adds a (intentionally not yet documented) [tk::classic::restore] proc that does the necessary option calls to reverse the changes.

  This means default "clean" look for classic, with back-out option for motif lovers (we could call the proc ::tk::classic::wishIwasAmotifProgrammer).


tkt_uuid: 1821174fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 67. Unix Window Operations
priority: 8
foundin: obsolete: 8.5b3
resolution: None
title: RenderBadPicture (invalid Picture parameter)
comment:
  Playing with BWidget, I've discovered some kind of error. How to repeat:

  1. Take the BWidget template from http://wiki.tcl.tk/8289

  2. Before last line ("main") insert a line containing:   rename send {}

  3. When the demo has been run - choose "Exit". There will be an error message:

  #v+
    X Error of failed request:  RenderBadPicture (invalid Picture parameter)
      Major opcode of failed request:  153 (RENDER)
      Minor opcode of failed request:  7 (RenderFreePicture)
      Picture id in failed request: 0x1200080
      Serial number of failed request:  996
      Current serial number in output stream:  1017
  #v-

  The problem doesn't occur in 8.4.12.

  Debian Etch, Tcl/Tk 8.5b1, BWidget 1.7


tkt_uuid: 1821939fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5b2
resolution: Duplicate
title: scroll wheel not working in ttk::treeview on OSX
comment:
  This is in Aqua only:  Using the widget demo, the tree view example ("A directory browser tree") shows incorrect behavior with the scroll wheel.  The widget & scrollbar will scroll down, but not up.  The scroll wheel works correctly for all other demos.  It also works correctly when the pointer is over the scrollbar.


tkt_uuid: 1822076fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 9 Immediate
foundin: obsolete: 8.5b1
resolution: Fixed
title: tk_SaveFile cannot browse to a path with spaces
comment:
  Test case (Tcl 8.5b1, Linux):

    % wish
    $ file mkdir "a b c"
    $ file attributes "a b c" -permissions 0
    $ tk_getSaveFile 
    # enter "a b c"


  bad option "warning": must be -default, -detail, -icon, -message, -parent, -title, or -type
  bad option "warning": must be -default, -detail, -icon, -message, -parent, -title, or -type
      while executing
  "error "bad option \"$cmdsw\": must be [tclListValidFlags cmd]""
      (procedure "tclParseConfigSpec" line 36)
      invoked from within
  "tclParseConfigSpec $w $specs "" $args"
      (procedure "tk::MessageBox" line 24)
      invoked from within
  "tk::MessageBox {*}$args"
      (procedure "tk_messageBox" line 2)
      invoked from within
  "tk_messageBox -type ok -parent $w -message -icon warning  [mc "Cannot change to the directory \"%1\$s\".\nPermission denied." $file]"
      (procedure "ListInvoke" line 14)
      invoked from within
  "ListInvoke $w [list $filename]"
      (procedure "::tk::dialog::file::OkCmd" line 13)
      invoked from within
  "::tk::dialog::file::OkCmd .__tk_filedialog"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 $data(-command)"
      (procedure "IconList_Invoke" line 5)
      invoked from within
  "IconList_Invoke $w"
      (procedure "tk::IconList_Double1" line 5)
      invoked from within
  "tk::IconList_Double1 .__tk_filedialog.icons 45 17"
      (command bound to event)


tkt_uuid: 1822391fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 9 Immediate
foundin: obsolete: 8.5b2
resolution: Fixed
title: segfault with photo put
comment:
  The put operation on a photo image causes a segfault with malformed input data. See code in attachment saved as file crash. Results when executed:

  % wish crash 
  ----- 8.4.15
  /usr/lib64/tcl8.4 /usr/lib64 /usr/lib /usr/lib64/tk8.4
  /usr/lib64/tcl8.4 /usr/lib64 /usr/lib /usr/lib64/tk8.4
  hello1
  Segmentation fault

  % /usr/local/tcl/8.5b2/bin/wish crash
  ----- 8.5b2
  /usr/local/tcl/8.5b2/lib/tcl8.5 /usr/local/tcl/8.5b2/lib /usr/local/tcl/8.5b2/lib/tk8.5 /usr/local/tcl/8.5b2/lib/tk8.5/ttk
  /usr/local/tcl/8.5b2/lib/tcl8.5 /usr/local/tcl/8.5b2/lib /usr/local/tcl/8.5b2/lib/tk8.5 /usr/local/tcl/8.5b2/lib/tk8.5/ttk
  hello1
  Segmentation fault

  Expected behavior: should not crash
  Tested on Gentoo 2007.0 i686, x86_64.


tkt_uuid: 1822410fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 76. Widget Tour
priority: 5 Medium
foundin: obsolete: 8.5b2
resolution: Fixed
title: Listbox demo and window resizing
comment:
  The Tk Widget demo "Listbox demonstration (well-known sayings)" has a listbox that does not stretch horizontally when the window size changes. This is awkward, since you cannot make the listbox wide enough to read all the text without scrolling.

  The simple solution is to change line 33 to:

   pack $w.frame -side top -expand yes -fill both

  And then, the -sticky options in lines 43 and 44 are too general. They do behave correctly, so this is no error, but what is meant, is probably:

   grid $w.frame.yscroll -row 0 -column 1 -rowspan 1 -columnspan 1 -sticky ns
   grid $w.frame.xscroll -row 1 -column 0 -rowspan 1 -columnspan 1 -sticky ew


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

  grid columnconfigure $w 0 -weight 1

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

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


tkt_uuid: 1824521fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 9 Immediate
foundin: obsolete: 8.5b2
resolution: Fixed
title: Using -bitmap crashes TkpDisplayMenuButton
comment:
  Exception:  EXC_BAD_ACCESS (0x0001)
  Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000050

  Thread 0 Crashed:
  0   libtk8.5.dylib      0x0b0b5a20 XCopyPlane + 96
  1   libtk8.5.dylib      0x0b0c25ac TkpDisplayMenuButton + 2466
  2   libtcl8.5.dylib     0x0a08f4a7 TclServiceIdle + 65
  3   libtcl8.5.dylib     0x0a0751f8 Tcl_DoOneEvent + 380
  4   libtk8.5.dylib      0x0b0c7ab8 TkMacOSXProcessWindowEvent + 746
  5   libtk8.5.dylib      0x0b0b84b6 TkMacOSXProcessEvent + 107
  6   libtk8.5.dylib      0x0b0cf9aa CarbonEventHandlerProc + 95
  7   com.apple.HIToolbox 0x92dec537 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1093
  8   com.apple.HIToolbox 0x92debbdc SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 304
  9   com.apple.HIToolbox 0x92debaa1 SendEventToEventTargetWithOptions + 55
  10  com.apple.HIToolbox 0x92df3123 ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 357
  11  com.apple.HIToolbox 0x92dec8ee DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 2044
  12  com.apple.HIToolbox 0x92debbdc SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 304
  13  com.apple.HIToolbox 0x92df2fbc SendEventToEventTarget + 56
  14  libtk8.5.dylib      0x0b0cfea7 TkMacOSXReceiveAndDispatchEvent + 136
  15  libtk8.5.dylib      0x0b0c3ea4 CarbonEventsCheckProc + 49
  16  libtcl8.5.dylib     0x0a0751da Tcl_DoOneEvent + 350
  17  libtk8.5.dylib      0x0b011fdb Tk_MainLoop + 36
  18  libtk8.5.dylib      0x0b01f184 Tk_MainEx + 1995
  19  wish                0x00002e97 main + 41
  20  wish                0x00002e52 _start + 216
  21  wish                0x00002d79 start + 41


tkt_uuid: 1824638fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 9 Immediate
foundin: obsolete: 8.5b2
resolution: Fixed
title: Aqua: wraplength 1 does not work correctly with ATSUI
comment:
  Is there difference of wraplength between 8.4.16 and 8.5 ?
  My environment 10.4.10, Powermac G4

  label .l -text abcd -wraplength 1
  pack .l

  Aqua TclTk 8.4.10
  each one letter, a new line feed
  a
  b
  c
  d

  Aqua TclTk 8.5b2
  the string "abcd" is displayed as one line.


tkt_uuid: 1825353fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 8
foundin: obsolete: 8.5b3
resolution: Fixed
title: Tiny fonts in Windows console window
comment:
  Console window has unreadable tiny fonts in Windows wish built with VC6 using the standard makefile.vc (with OPTS=symbols).

  The system is WinXP SP2 Pro (Russian).
  Screen resolution: 1280x1024
  % winfo pixels . 1i
  96
  (which corresponds to the system setting)

  In the freshly started wish85g.exe:

  % console eval { foreach f [font names] { puts "$f\n[font config $f]" } }
  fixed
  -family Courier -size 7 -weight normal -slant roman -underline 0 -overstrike 0
  TkConsoleFont
  -family Courier -size 7 -weight normal -slant roman -underline 0 -overstrike 0
  oemfixed
  -family Terminal -size 9 -weight normal -slant roman -underline 0 -overstrike 0
  TkDefaultFont
  -family Tahoma -size 8 -weight normal -slant roman -underline 0 -overstrike 0
  TkMenuFont
  -family Tahoma -size 8 -weight normal -slant roman -underline 0 -overstrike 0
  ansifixed
  -family Courier -size 7 -weight normal -slant roman -underline 0 -overstrike 0
  systemfixed
  -family Fixedsys -size 10 -weight normal -slant roman -underline 0 -overstrike 0
  TkHeadingFont
  -family Tahoma -size 8 -weight normal -slant roman -underline 0 -overstrike 0
  device
  -family System -size 10 -weight bold -slant roman -underline 0 -overstrike 0
  TkTooltipFont
  -family Tahoma -size 8 -weight normal -slant roman -underline 0 -overstrike 0
  defaultgui
  -family {MS Shell Dlg} -size 8 -weight normal -slant roman -underline 0 -overstrike 0
  TkTextFont
  -family Tahoma -size 8 -weight normal -slant roman -underline 0 -overstrike 0
  ansi
  -family {MS Sans Serif} -size 8 -weight normal -slant roman -underline 0 -overstrike 0
  TkCaptionFont
  -family Tahoma -size 8 -weight bold -slant roman -underline 0 -overstrike 0
  system
  -family System -size 10 -weight bold -slant roman -underline 0 -overstrike 0
  TkSmallCaptionFont
  -family Tahoma -size 8 -weight bold -slant roman -underline 0 -overstrike 0
  TkFixedFont
  -family Courier -size 7 -weight normal -slant roman -underline 0 -overstrike 0
  TkIconFont
  -family Tahoma -size 8 -weight normal -slant roman -underline 0 -overstrike 0

  So while the system fonts have (the default) size of 8 console font is 7 which is too small.


tkt_uuid: 1826019fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 34. [tk_chooseColor]
priority: 5 Medium
foundin: None
resolution: None
title: Update for the default colour picker
comment:
  With the coming release of Tk 8.5 Donal Fellows asked if 
  anybody was interested in updating the colour picker
  (::tk::dialog::color::) that is used for platforms that
  do not offer a native facility. I volunteered.

  The attached source uses Tile widgets instead of Tk 
  widgets, where possible. Further improvements: a better alignment for the label, entry and colour bars.

  There is one smallish issue: the Alt-letter bindings
  have no effect anymore. This is due to the Tile 
  widgets - if you change ::ttk::label into ::tk::label
  they work again.

  Furthermore: I needed extra padding for the selFrame 
  widget (line 303) otherwise the border of the surrounding
  widget was incomplete (especially with the clam theme
  under Windows)


tkt_uuid: 1832015fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: canvas scale documentation cryptic
comment:
  The canvas documentation states for scale:

  Rescale all of the items given by tagOrId in canvas coordinate space.

  This seems unnecessary cryptic to me. I think the following would be clearer:

  Rescale the coordinates of all the items given by tagOrId.


tkt_uuid: 1833775fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: None
resolution: Fixed
title: font measure error when text starts like -displayof
comment:
  Observed by KaKaRoTo on Tcl Chat

  Font measure will give an error if -displayof is not specified and the text is a substring of displayof.

  % font measure Courier "-d"
  value for "-displayof" missing

  If objc==4 the displayof value should not be checked. This can be fixed by the following change in tkFont.c

   diff tkFont.c tkFont.c.orig
  724,727c724
  <       skip = 0 ;
  <       if (objc==6) {
  <           skip = TkGetDisplayOf(interp, objc - 3, objv + 3, &tkwin);
  <       }
  ---
  >       skip = TkGetDisplayOf(interp, objc - 3, objv + 3, &tkwin);


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

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

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

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

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

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


tkt_uuid: 1836621fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 8
foundin: obsolete: 8.5b3
resolution: Fixed
title: Documentation missing on -outlineoffset option
comment:
  The item option '-outlineoffset' for the oval and rectangle items on the canvas is not documented in the manual page. It could be something like this:

  -outlineoffset _bitmap_
     Specifies the offset of the outline stipple
     pattern. The offset value  can  be  of  the
     form x,y or side,  where  side can be n, ne,
     e, se, s, sw, w, nw, or center. This option
     only  has an  effect,  when the  outline is
     drawn as a stipple pattern.  Works only for
     the X11 environment.


tkt_uuid: 1841991fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: None
resolution: Invalid
title: Missing message box
comment:
  TCL has a askyesnocancel msgbox,
  The define are made in tkMessageBox,
  but there is no function askyesnocancel

  Could be a two minute good add for a next version


tkt_uuid: 1843410fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 33. Generic Dialog Support
priority: 5 Medium
foundin: None
resolution: None
title: Additional option (f.e. "-description")
comment:
  It is quite common today to have additional, short description of chosen buttons/menu entries etc. either on kind of statusbar, or in the "tooltip"-form. Currently such description has to be added using some additional structures, while it can be avoided by having additional option: let's here call it "-description" - which can be then easily called using "cget". That "description" (which itself is a simple text, and nothing more) could even be set in form similar to "-command": using {} dynamically, using "" statically - which will make the ways of assignment even broader.

  A short example, how could it look like:

  $w.menu add cascade -label "File" -description "File operations menu"

  bind Menu <<MenuSelect>> {
    global menustatus
    if {[catch {%W entrycget active -description} label]} {
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
         set label "    "
    }
    set menustatus $label
    update idletasks
  }

  Such option could be added to all the "interactive" widgets - those which can be used to run commands, or choose options - of course, it won't be necessarily for "separators" (or can be ignored in such case).

  Such way adding/changing "tooltips" (or statusbar texts) contents would be much more easier during both creation and maintenance.


tkt_uuid: 1843539fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 3 Low
foundin: obsolete: 8.4.18
resolution: None
title: enter bindings after activation fire only after first move
comment:
  Greetings,

  in Tk8.4.16/Aqua "Enter" bindings of a window fire only after the
  first move of the mouse after the window was activated.
  To reproduce, run the following script:
  -snip-
  toplevel .t1
  toplevel .t2
  bind .t1 <Enter> "puts Enter-T1;update"
  bind .t2 <Enter> "puts Enter-T2;update"
  -snap-

  Activate the first toplevel by clicking right into it (not onto the title bar),
  but do not move the mouse.
  Nohing happens, but I expected the enter binding to fire immediately.
  Move the mouse. The binding fires.

  best regards,
  Randolf


tkt_uuid: 1844034fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: None
resolution: None
title: Clipboard doesn't persist after quit
comment:
  On OS X (and apparently Windows as well), the Tk clipboard is 'lazy' - it doesn't appear to be copied to the main system clipboard until asked.  If the Tk app is quit before this happens, the copied text is lost forever.

  Obviously this has its uses (say, copying large chunks of video), but makes other workflows very frustrating.  I use gitk for browsing my git commits - typical workflow would be to fire up gitk from the terminal, find the commit I'm interested, copy the relevant SHA1 id, quit gitk, and paste that id to the terminal.  Tk's current pasteboard implementation prevents this.

  Are there any workarounds?


tkt_uuid: 1844143fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 79. L10N
priority: 9 Immediate
foundin: None
resolution: Accepted
title: Danish message catalog
comment:
  Tk does not have a danish message catalog
  in library/msgs. This patch supplies these (see attachted file 'da.msg').


tkt_uuid: 1844749fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: Tk build fails with MinGW on Windows
comment:
  When building a shared lib, Tk HEAD on windows using mingw, the link step fails, because the ole32.lib and oleaut32.lib have been removed from tcl.m4 ( r 1.47 ) why were these libraries removed?

  after:
  ./configure --enable-threads --prefix=/usr
  make


  The link error is:

  Creating library file: libtk85.a
  tkWinSend.o:tkWinSend.c:(.text+0x160): undefined reference to `GetRunningObjectTable@8'
  tkWinSend.o:tkWinSend.c:(.text+0x187): undefined reference to `CreateBindCtx@8'
  tkWinSend.o:tkWinSend.c:(.text+0x1b4): undefined reference to `CreateFileMoniker@8'
  tkWinSend.o:tkWinSend.c:(.text+0x212): undefined reference to `CreateFileMoniker@8'
  tkWinSend.o:tkWinSend.c:(.text+0x389): undefined reference to `VariantInit@4'
  tkWinSend.o:tkWinSend.c:(.text+0x39b): undefined reference to `VariantInit@4'
  tkWinSend.o:tkWinSend.c:(.text+0x3e6): undefined reference to `SysAllocString@4'
  tkWinSend.o:tkWinSend.c:(.text+0x47a): undefined reference to `VariantChangeType@16'
  tkWinSend.o:tkWinSend.c:(.text+0x4d8): undefined reference to `SysFreeString@4'
  tkWinSend.o:tkWinSend.c:(.text+0x4ea): undefined reference to `SysFreeString@4'
  tkWinSend.o:tkWinSend.c:(.text+0x4fc): undefined reference to `SysFreeString@4'
  tkWinSend.o:tkWinSend.c:(.text+0x50e): undefined reference to `VariantClear@4'
  tkWinSend.o:tkWinSend.c:(.text+0x830): undefined reference to `SysAllocString@4'
  tkWinSend.o:tkWinSend.c:(.text+0x84c): undefined reference to `SysAllocString@4'
  tkWinSend.o:tkWinSend.c:(.text+0x865): undefined reference to `CreateErrorInfo@4'
  tkWinSend.o:tkWinSend.c:(.text+0x8eb): undefined reference to `SetErrorInfo@8'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x10): undefined reference to `CoTaskMemAlloc@4'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x167): undefined reference to `CoTaskMemFree@4'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x31e): undefined reference to `VariantInit@4'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x342): undefined reference to `VariantChangeType@16'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x362): undefined reference to `VariantClear@4'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x3af): undefined reference to `VariantInit@4'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x3cf): undefined reference to `VariantChangeType@16'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x3f7): undefined reference to `SysStringLen@4'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x433): undefined reference to `SysStringLen@4'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x47a): undefined reference to `VariantInit@4'
  tkWinSendCom.o:tkWinSendCom.c:(.text+0x4a9): undefined reference to `SysAllocString@4'
  collect2: ld returned 1 exit status
  make: *** [tk85.dll] Error 1 


tkt_uuid: 1845066fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 71. Error Handling
priority: 5 Medium
foundin: obsolete: 8.5b3
resolution: Invalid
title: grumpy "package require"
comment:
  Current version unnecessarily treats an *existing* different version of any package as error. I'll describe the thing using sqlite3 module as example:

  In Tcl8.4, when I requested sqlite3 package:

  tclsh8.4 [~]catch {package require sqlite3} errmsg

  attempt to provide package sqlite3 3.3 failed: package sqlite3 3.4.2 provided instead
  0
     
  ...and it was OK. Although it didn't find version 3.3 - a newer version has been found instead, so the result message "OK" (0) was quite proper.

  And now, while using 8.5b3:

  tclsh8.5 [~]catch {package require sqlite3} errmsg
  1
     
  No, it shouldn't be so, I suppose. When I'm not using "catch", it can find the package anyway:

  tclsh8.5 [~]package require sqlite3
  attempt to provide package sqlite3 3.3 failed: package sqlite3 3.4.2 provided instead
    while evaluating {package require sqlite3}

  (...of course, I realize, the package has been
  found while using "catch" too).

  What I have in mind, that it shouldn't be reported as error (1) - because I didn't specified an exact version; just wrote: "load any available sqlite3 package", what has been done. So, why error? The "difference in version" has been already reported by a warning message (and it's quite enough) - but as long, as sqlite3 module can be loaded, it shouldn't be treated as "package require error".

  Yes, I know: there's a need to make a little change pkgIndex.tcl - but why "package require" has been made so grumpy in 8.5, while its functionality in 8.4 was logical? "No (real) error - no `1' in output when catch-ing". Because version difference - noticed in pkgIndex - isn't, in fact, any real error (package has been found and loaded, anyway), and message "other version provided instead" is quite enough in such case.


tkt_uuid: 1845164fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5b3
resolution: Fixed
title: ttk::combobox trims display text in long view
comment:
  If you run the combobox demo, see code, and then add "-fill x -expand 1" to the final 4 pack lines and rerun, you can see this in the head.  Resize the window a bit wider for obvious effect.

  If I type in 0123456789abcdefghijklmnopqrst into the top entry, it stops displaying at l (ell).  If you play around with the cursor, you see that the "entry" portion of the combobox just seems to be truncated.

  No problem seen on X11, Win32.


tkt_uuid: 1845590fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 02. Appearance
priority: 5 Medium
foundin: None
resolution: Later
title: ttk_setPalette wanted
comment:
  tk_setPalette is unable to change the palette used by "themed widgets" - so, there's a need for such counterpart.

  Nowadays the users are expecting the applications with sophisticated "look & feel" - and because of this a demand for "skinnable user interfaces". Although making "skins" could require a lot of work to change every single widget, it could be in some way replaced using present "ttk styled widgets", but *together* with possibility to change the colours - which, unfortunately, currently isn't available for themed widgets.

  I'm not sure - but it seems, that the existing routines used by tk_setPalette, tested during years of development, could be used in suggested ttk_setPalette as well, so it wouldn't require much work to add such command?


tkt_uuid: 1845899fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 8
foundin: obsolete: 8.4.17
resolution: Fixed
title: wm transient creates wrong window class on OS X
comment:
  On the 8.5 head, if you do:

  toplevel .t ; wm transient .t . ; #avoid interim update

  then the window created with like an overrideredirect window - this isn't what users want, and is a regression from earlier releases.  Don't have time to look into this now, but it is a blocker bug.


tkt_uuid: 1847002fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 56. [grab]
priority: 5 Medium
foundin: obsolete: 8.4.16
resolution: Fixed
title: User may activate other toplevels.
comment:
  On Windows, when there is a grab, the user can interate with other toplevels on the same app using the taskbar.

  To replicate this, on wish, execute this code:

  toplevel .t ; grab .t

  You can activate the main toplevel (the one titled "wish84") clicking its icon on the windows taskbar. It comes to the front, possibly hiding the toplevel that has the grab. This is annoying and confusing. I know a case where the user rebooted Windows, after apparently being stuck with an unresponsive application. It goes against the semantics of grab, too. No Tk event is fired, so the programmer can do nothing to prevent this.

  In tkWinWm.c, the case where the user clicks onto a non-grabbed toplevel is managed (see WmProc, handling of WM_MOUSEACTIVATE message). Putting similar code on the handling of the WM_ACTIVATE message resolves the problem by making sure that no matter what toplevel the user tries to activate with the taskbar, if there is a grab active, the toplevel that has the grab stays active and on top.

  There is other related problem with the current implementation of grab: the user can interact with the system menu of the non-grabbed toplevels, thus being able to close, minimize, etc them. An ideal solution would be to disable the system menu for all toplevels except the grabbed one, and enable it again when the grab is released. However, an improvement over the current situation is to ignore WM_SYSCOMMAND when there is a grab (except for the grabbed toplevel).

  Finally, IMO the user should be not allowed to minimize a grabbed window.

  Patch implementing all this attached.

  To recapitulate, it is my undersanding that, when there is a grab, the user shouldn't be allowed to interact with those parts of the application's GUI that are outside the limits of the grabbed portion. Although the patch does not resolve enterely the problem, it avoids GUI states that can cause trouble and confussion both to the user and developer.


tkt_uuid: 1847018fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 67. Unix Window Operations
priority: 8
foundin: obsolete: 8.5b3
resolution: None
title: X Error ...
comment:
  tk8.5b3 compiled under MacOSX Leopard + X11,
  suddenly crashes with:

  X Error of failed request:  BadMatch (invalid parameter attributes)
    Major opcode of failed request:  70 (X_PolyFillRectangle)
    Serial number of failed request:  543
    Current serial number in output stream:  544


tkt_uuid: 1847925fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 61. Safe Tk
priority: 5 Medium
foundin: obsolete: 8.5b3
resolution: Fixed
title: safe-1.2 fails
comment:
  New failure on the HEAD:

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

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

  ---- Result was:
  bell cd clipboard encoding exec exit fconfigure file glob grab load menu open pwd selection send socket source toplevel wm
  ---- Result should have been (exact matching):
  bell cd clipboard encoding exec exit fconfigure file glob grab load menu open pwd selection send socket source toplevel unload wm
  ==== safe-1.2 FAILED

  Probably releated to Tcl Bug 1662436.


tkt_uuid: 1847926fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.5b3
resolution: None
title: case of [font actual] results
comment:
  Some test failures:

  ==== unixfont-2.6 TkpGetFontFromAttributes: fallback to fixed family FAILED
  ==== Contents of test case:

      lindex [font actual {-family fixed -size 10}] 1

  ---- Result was:
  Fixed
  ---- Result should have been (exact matching):
  fixed
  ==== unixfont-2.6 FAILED



  ==== unixfont-2.8 TkpGetFontFromAttributes: loop over returned font names FAILED
  ==== Contents of test case:

      lindex [font actual {-family fixed -size 31}] 1

  ---- Result was:
  Fixed
  ---- Result should have been (exact matching):
  fixed
  ==== unixfont-2.8 FAILED



  ==== unixfont-2.9 TkpGetFontFromAttributes: reject adobe courier if possible FAILED
  ==== Contents of test case:

      lindex [font actual {-family courier}] 1

  ---- Result was:
  Courier
  ---- Result should have been (exact matching):
  courier
  ==== unixfont-2.9 FAILED


  If these are indications of some trouble,
  then a fix is in order.  If not, then some
  custom -match can give the tests the flexibility
  they need.


tkt_uuid: 1850888fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: None
resolution: None
title: Dead code: [testfont subfont], TkpGetSubFonts
comment:
  Each of macosx/tkMacOSXFont.c, unix/tkUnixFont.c, unix/tkUnixRFont.c, and win/tkWinFont.c contain a routine TkpGetSubFonts().  This is only called from  TestfontObjCmd() in generic/tkTest.c to implement the [testfont subfonts] command.

  However, [testfont subfonts] is not called anywhere in the test suite.  Can this go away?


tkt_uuid: 1851526fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 27. Objects
priority: 8
foundin: None
resolution: None
title: 8.5 breaks some Tkinter text widgets
comment:
  8.5 is causing the Tkinter EditorWindow class to break for some unknown reason.  When the user clicks <1> the event is delivered, but for some reason the Tk code isn't behaving properly.  Therefore you can't select text for copying and pasting.

  This is this code that seems to break with 8.5, and I'm not sure why yet:
  Python-2.5.1/Lib/idlelib/EditorWindow.py

  The same code works fine with Python 2.5.1 using Tcl/Tk 8.4.

  Here's what I've done so far:
  I've verified that the events are being delivered with this code:
  print(text.bind_class ("Text", "<1>", None, None)) 
  cmd = text.bind_class("Text", "<1>", None, None)
  cmd = 'puts TextB1;' + cmd
  text.bind_class ("Text", "<1>", cmd)

  I've gone hunting in various other places for the bug, with little success.

  You can run: /path/to/8.5/using/python EditorWindow.py 

  Whatever this bug is breaks IDLE (the standard Python editor that uses Tkinter).

  In a related note: they are using MacOSX private symbols, so it may already be broken on Mac OS X if those are MODULE_SCOPEd. Some sort of better cooperation is needed between the Tkinter and Tk developers.


tkt_uuid: 1852332fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 5 Medium
foundin: obsolete: 8.5b3
resolution: Duplicate
title: test suite window-2.9 test hangs
comment:
  sparc solaris 9, sun c compiler, sun's gnome desktop distribution.

  tcl/tk rc4 snapshot configured with options \"'--prefix=/projects/sprs_lwv/tcl85' '--enable-shared' '--enable-symbols' '--enable-stubs' '--enable-64bit' '--enable-threads' '--prefix=/tmp/.lwv/tcl85' '--with-tcl=/tmp/.lwv/tcl85/lib' 'CC=cc'\"

  This test begins displaying some windows - then doesn't progress. When, after 5 minutes, I issue a kill -15 against the process, I see:

  window.test

  ==== window-2.9 Tk_DestroyWindow, Destroy bindings
          evaluated after exit FAILED
  ==== Contents of test case:

      set code [loadTkCommand]
      append code {
          toplevel .t1
          toplevel .t2
          update
          bind .t2 <Destroy> {puts "Destroy .t2" ; exit 1}
          bind .t1 <Destroy> {puts "Destroy .t1" ; exit 0}
          destroy .t2
      }
      set script [makeFile $code script]
      if {[catch {exec [interpreter] $script -geometry 10x10+0+0} msg]} {
          set error 1
      } else {
          set error 0
      }
      removeFile script
      list $error $msg

  ---- Result was:
  1 {Destroy .t2
  Destroy .t1
  child killed: software termination signal}
  ---- Result should have been (exact matching):
  0 {Destroy .t2
  Destroy .t1}
  ==== window-2.9 FAILED


  For some reason, the Destroy doesn't appear to be running.


tkt_uuid: 1852338fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 8
foundin: obsolete: 8.5.1
resolution: Duplicate
title: [wm manage] sets up struct overwriting
comment:
  sparc solaris 9, sun c compiler, compiled with options \"'--prefix=/projects/sprs_lwv/tcl85' '--enable-shared' '--enable-symbols' '--enable-stubs' '--enable-64bit' '--enable-threads' '--prefix=/tmp/.lwv/tcl85' '--with-tcl=/tmp/.lwv/tcl85/lib' 'CC=cc'\"

  When the tk test suite reached wm.test, I see:

  wm.test
  Segmentation Fault - core dumped
  gmake: *** [test-classic] Error 139

   $ dbx tktest core
  For information about new features see `help changes'
  To remove this message, put `dbxenv suppress_startup_message 7.0' in your .dbxrc
  Reading tktest
  core file header read successfully
  Reading ld.so.1
  Reading libtk8.5.so
  Reading libtcl8.5.so
  Reading libpthread.so.1
  Reading libX11.so.4
  Reading libXext.so.0
  Reading libdl.so.1
  Reading libsocket.so.1
  Reading libnsl.so.1
  Reading libm.so.1
  Reading libc.so.1
  Reading libmp.so.2
  Reading libc_psr.so.1
  Reading libthread.so.1
  detected a multithreaded program
  t@1 (l@1) terminated by signal SEGV (no mapping at the fault address)
  Current function is Tk_FreeConfigOptions
   1604                   Tcl_DecrRefCount(oldPtr);

  (dbx 1) where
  current thread: t@1
  =>[1] Tk_FreeConfigOptions(recordPtr = 0x10087e130 "", optionTable = 0x10064d9e0, tkwin = 0x1006d7ac0), line 1604 in "tkConfig.c"
    [2] DestroyButton(butPtr = 0x10087e130), line 1002 in "tkButton.c"
    [3] ButtonEventProc(clientData = 0x10087e130, eventPtr = 0xffffffff7ffeed28), line 1455 in "tkButton.c"
    [4] Tk_HandleEvent(eventPtr = 0xffffffff7ffeed28), line 1401 in "tkEvent.c"
    [5] Tk_DestroyWindow(tkwin = 0x1006d7ac0), line 1411 in "tkWindow.c"
    [6] Tk_DestroyWindow(tkwin = 0x100cb95b0), line 1352 in "tkWindow.c"
    [7] Tk_DestroyObjCmd(clientData = 0x100074540, interp = 0x100043e90, objc = 2, objv = 0x10005f5e0), line 468 in "tkCmds.c"
    [8] TclEvalObjvInternal(interp = 0x100043e90, objc = 2, objv = 0x10005f5e0, command = 0x10021b200 "destroy .t", length = 10, flags = 0), line 3647 in "tclBasic.c"
    [9] TclEvalEx(interp = 0x100043e90, script = 0x10021b200 "destroy .t", numBytes = 10, flags = 262144, line = 1), line 4296 in "tclBasic.c"
    [10] Tcl_EvalEx(interp = 0x100043e90, script = 0x10021b200 "destroy .t", numBytes = 10, flags = 262144), line 4000 in "tclBasic.c"
    [11] TclEvalObjEx(interp = 0x100043e90, objPtr = 0x100abeff0, flags = 262144, invoker = (nil), word = 0), line 4673 in "tclBasic.c"
    [12] Tcl_EvalObjCmd(dummy = (nil), interp = 0x100043e90, objc = 3, objv = 0x10005f328), line 677 in "tclCmdAH.c"
    [13] TclEvalObjvInternal(interp = 0x100043e90, objc = 3, objv = 0x10005f328, command = 0xffffffffffffffff "", length = -1, flags = 0), line 3647 in "tclBasic.c"
    [14] TclExecuteByteCode(interp = 0x100043e90, codePtr = 0x100452240), line 2211 in "tclExecute.c"
    [15] TclObjInterpProcCore(interp = 0x100043e90, procNameObj = 0x100ab6370, skip = 1, errorProc = 0x7fffffff7f59efe8 = &`libtcl8.5.so`tclProc.c`MakeProcError(Tcl_Interp *interp, Tcl_Obj *procNameObj)), line 1721 in "tclProc.c"
    [16] TclObjInterpProc(clientData = 0x1004595d0, interp = 0x100043e90, objc = 1, objv = 0x10005f118), line 1615 in "tclProc.c"
    [17] InvokeImportedCmd(clientData = 0x10043d110, interp = 0x100043e90, objc = 1, objv = 0x10005f118), line 1890 in "tclNamesp.c"
    [18] TclEvalObjvInternal(interp = 0x100043e90, objc = 1, objv = 0x10005f118, command = 0x100bb6115 "deleteWindows\n    set result [list]\n    toplevel .t\n    toplevel .t.t\n    button .t.t.b -text "Manage This"\n    pack .t.t.b\n    update\n    lappend result [winfo manage .t.t]\n    lappend result [winfo toplevel .t.t.b]\n    wm forget .t.t\n    wm forget .t.t ; # second call should be a no-op\n    pack .t.t\n    update\n    lappend result [winfo manage .t.t]\n    lappend result [winfo toplevel .t.t.b]\n    wm manage .t.t\n    wm manage .t.t ; # second call should be a no-op\n    wm deiconify .t.t\n    update\n    lappend" ..., length = 14, flags = 0), line 3647 in "tclBasic.c"
    [19] TclEvalEx(interp = 0x100043e90, script = 0x100bb6110 "\n    deleteWindows\n    set result [list]\n    toplevel .t\n    toplevel .t.t\n    button .t.t.b -text "Manage This"\n    pack .t.t.b\n    update\n    lappend result [winfo manage .t.t]\n    lappend result [winfo toplevel .t.t.b]\n    wm forget .t.t\n    wm forget .t.t ; # second call should be a no-op\n    pack .t.t\n    update\n    lappend result [winfo manage .t.t]\n    lappend result [winfo toplevel .t.t.b]\n    wm manage .t.t\n    wm manage .t.t ; # second call should be a no-op\n    wm deiconify .t.t\n    update\n    la" ..., numBytes = 588, flags = 262144, line = 2), line 4296 in "tclBasic.c"
    [20] Tcl_EvalEx(interp = 0x100043e90, script = 0x100bb6110 "\n    deleteWindows\n    set result [list]\n    toplevel .t\n    toplevel .t.t\n    button .t.t.b -text "Manage This"\n    pack .t.t.b\n    update\n    lappend result [winfo manage .t.t]\n    lappend result [winfo toplevel .t.t.b]\n    wm forget .t.t\n    wm forget .t.t ; # second call should be a no-op\n    pack .t.t\n    update\n    lappend result [winfo manage .t.t]\n    lappend result [winfo toplevel .t.t.b]\n    wm manage .t.t\n    wm manage .t.t ; # second call should be a no-op\n    wm deiconify .t.t\n    update\n    la" ..., numBytes = 588, flags = 262144), line 4000 in "tclBasic.c"
    [21] TclEvalObjEx(interp = 0x100043e90, objPtr = 0x100af6a00, flags = 262144, invoker = (nil), word = 0), line 4673 in "tclBasic.c"
    [22] Tcl_EvalObjEx(interp = 0x100043e90, objPtr = 0x100af6a00, flags = 262144), line 4554 in "tclBasic.c"
    [23] Tcl_UplevelObjCmd(dummy = (nil), interp = 0x100043e90, objc = 1, objv = 0x10005ee70), line 911 in "tclProc.c"
    [24] TclEvalObjvInternal(interp = 0x100043e90, objc = 3, objv = 0x10005ee60, command = 0xffffffffffffffff "", length = -1, flags = 0), line 3647 in "tclBasic.c"
    [25] TclExecuteByteCode(interp = 0x100043e90, codePtr = 0x100365d40), line 2211 in "tclExecute.c"
    [26] TclObjInterpProcCore(interp = 0x100043e90, procNameObj = 0x100d18960, skip = 1, errorProc = 0x7fffffff7f59efe8 = &`libtcl8.5.so`tclProc.c`MakeProcError(Tcl_Interp *interp, Tcl_Obj *procNameObj)), line 1721 in "tclProc.c"
    [27] TclObjInterpProc(clientData = 0x100251ef0, interp = 0x100043e90, objc = 3, objv = 0x100922440), line 1615 in "tclProc.c"
    [28] TclEvalObjvInternal(interp = 0x100043e90, objc = 3, objv = 0x100922440, command = (nil), length = 0, flags = 262144), line 3647 in "tclBasic.c"
    [29] Tcl_EvalObjv(interp = 0x100043e90, objc = 3, objv = 0x100922440, flags = 262144), line 3842 in "tclBasic.c"
    [30] TclEvalObjEx(interp = 0x100043e90, objPtr = 0x1008b6730, flags = 262144, invoker = (nil), word = 0), line 4643 in "tclBasic.c"
    [31] Tcl_EvalObjEx(interp = 0x100043e90, objPtr = 0x1008b6730, flags = 262144), line 4554 in "tclBasic.c"
    [32] Tcl_UplevelObjCmd(dummy = (nil), interp = 0x100043e90, objc = 1, objv = 0x10005ed00), line 911 in "tclProc.c"
    [33] TclEvalObjvInternal(interp = 0x100043e90, objc = 3, objv = 0x10005ecf0, command = 0xffffffffffffffff "", length = -1, flags = 0), line 3647 in "tclBasic.c"
    [34] TclExecuteByteCode(interp = 0x100043e90, codePtr = 0x100858cb0), line 2211 in "tclExecute.c"
    [35] TclObjInterpProcCore(interp = 0x100043e90, procNameObj = 0x10020f570, skip = 1, errorProc = 0x7fffffff7f59efe8 = &`libtcl8.5.so`tclProc.c`MakeProcError(Tcl_Interp *interp, Tcl_Obj *procNameObj)), line 1721 in "tclProc.c"
    [36] TclObjInterpProc(clientData = 0x1001356e0, interp = 0x100043e90, objc = 3, objv = 0x1006ff3c0), line 1615 in "tclProc.c"
    [37] TclEvalObjvInternal(interp = 0x100043e90, objc = 3, objv = 0x1006ff3c0, command = (nil), length = 0, flags = 262144), line 3647 in "tclBasic.c"
    [38] Tcl_EvalObjv(interp = 0x100043e90, objc = 3, objv = 0x1006ff3c0, flags = 262144), line 3842 in "tclBasic.c"
    [39] TclEvalObjEx(interp = 0x100043e90, objPtr = 0x100212810, flags = 262144, invoker = (nil), word = 0), line 4643 in "tclBasic.c"
    [40] Tcl_EvalObjEx(interp = 0x100043e90, objPtr = 0x100212810, flags = 262144), line 4554 in "tclBasic.c"
    [41] Tcl_UplevelObjCmd(dummy = (nil), interp = 0x100043e90, objc = 1, objv = 0x10005eb88), line 911 in "tclProc.c"
    [42] TclEvalObjvInternal(interp = 0x100043e90, objc = 3, objv = 0x10005eb78, command = 0xffffffffffffffff "", length = -1, flags = 0), line 3647 in "tclBasic.c"
    [43] TclExecuteByteCode(interp = 0x100043e90, codePtr = 0x100bc0030), line 2211 in "tclExecute.c"
    [44] TclObjInterpProcCore(interp = 0x100043e90, procNameObj = 0x10020fcf0, skip = 1, errorProc = 0x7fffffff7f59efe8 = &`libtcl8.5.so`tclProc.c`MakeProcError(Tcl_Interp *interp, Tcl_Obj *procNameObj)), line 1721 in "tclProc.c"
    [45] TclObjInterpProc(clientData = 0x1002be230, interp = 0x100043e90, objc = 5, objv = 0x10005df80), line 1615 in "tclProc.c"
    [46] InvokeImportedCmd(clientData = 0x100905760, interp = 0x100043e90, objc = 5, objv = 0x10005df80), line 1890 in "tclNamesp.c"
    [47] TclEvalObjvInternal(interp = 0x100043e90, objc = 5, objv = 0x10005df80, command = 0x100dab74d "test wm-manage-1.2 {} {\n    deleteWindows\n    set result [list]\n    toplevel .t\n    toplevel .t.t\n    button .t.t.b -text "Manage This"\n    pack .t.t.b\n    update\n    lappend result [winfo manage .t.t]\n    lappend result [winfo toplevel .t.t.b]\n    wm forget .t.t\n    wm forget .t.t ; # second call should be a no-op\n    pack .t.t\n    update\n    lappend result [winfo manage .t.t]\n    lappend result [winfo toplevel .t.t.b]\n    wm manage .t.t\n    wm manage .t.t ; # second call should be a no-op\n    wm deiconify" ..., length = 639, flags = 0), line 3647 in "tclBasic.c"
    [48] TclEvalEx(interp = 0x100043e90, script = 0x100d9cb40 "# This file is a Tcl script to test out Tk's interactions with\n# the window manager, including the "wm" command.  It is organized\n# in the standard fashion for Tcl tests.\n#\n# Copyright (c) 1992-1994 The Regents of the University of California.\n# Copyright (c) 1994-1997 Sun Microsystems, Inc.\n# Copyright (c) 1998-1999 by Scriptics Corporation.\n# All rights reserved.\n#\n# RCS: @(#) $Id$\n\n# This file tests window manager interactions that work across\n# platforms. Window manager tests that only work on a specifi" ..., numBytes = 61331, flags = 0, line = 2058), line 4296 in "tclBasic.c"
    [49] Tcl_EvalEx(interp = 0x100043e90, script = 0x100d9cb40 "# This file is a Tcl script to test out Tk's interactions with\n# the window manager, including the "wm" command.  It is organized\n# in the standard fashion for Tcl tests.\n#\n# Copyright (c) 1992-1994 The Regents of the University of California.\n# Copyright (c) 1994-1997 Sun Microsystems, Inc.\n# Copyright (c) 1998-1999 by Scriptics Corporation.\n# All rights reserved.\n#\n# RCS: @(#) $Id$\n\n# This file tests window manager interactions that work across\n# platforms. Window manager tests that only work on a specifi" ..., numBytes = 61331, flags = 0), line 4000 in "tclBasic.c"
    [50] Tcl_FSEvalFileEx(interp = 0x100043e90, pathPtr = 0x100431450, encodingName = (nil)), line 1826 in "tclIOUtil.c"
    [51] Tcl_SourceObjCmd(dummy = (nil), interp = 0x100043e90, objc = 2, objv = 0x1008e43c0), line 955 in "tclCmdMZ.c"
    [52] TclEvalObjvInternal(interp = 0x100043e90, objc = 2, objv = 0x1008e43c0, command = (nil), length = 0, flags = 262144), line 3647 in "tclBasic.c"
    [53] Tcl_EvalObjv(interp = 0x100043e90, objc = 2, objv = 0x1008e43c0, flags = 262144), line 3842 in "tclBasic.c"
    [54] TclEvalObjEx(interp = 0x100043e90, objPtr = 0x1008b5bc0, flags = 262144, invoker = (nil), word = 0), line 4643 in "tclBasic.c"
    [55] Tcl_EvalObjEx(interp = 0x100043e90, objPtr = 0x1008b5bc0, flags = 262144), line 4554 in "tclBasic.c"
    [56] Tcl_UplevelObjCmd(dummy = (nil), interp = 0x100043e90, objc = 1, objv = 0x10005dc88), line 911 in "tclProc.c"
    [57] TclEvalObjvInternal(interp = 0x100043e90, objc = 3, objv = 0x10005dc78, command = 0xffffffffffffffff "", length = -1, flags = 0), line 3647 in "tclBasic.c"
    [58] TclExecuteByteCode(interp = 0x100043e90, codePtr = 0x10063fbc0), line 2211 in "tclExecute.c"
    [59] TclCompEvalObj(interp = 0x100043e90, objPtr = 0x100ace8a0, invoker = 0x10005da88, word = 2), line 1362 in "tclExecute.c"
    [60] TclEvalObjEx(interp = 0x100043e90, objPtr = 0x100ace8a0, flags = 0, invoker = 0x10005da88, word = 2), line 4762 in "tclBasic.c"

    [61] Tcl_IfObjCmd(dummy = (nil), interp = 0x100043e90, objc = 5, objv = 0x10005dad8), line 303 in "tclCmdIL.c"
    [62] TclEvalObjvInternal(interp = 0x100043e90, objc = 5, objv = 0x10005dad8, command = 0x1002c7d25 "if {[singleProcess]} {\n^I    incr numTestFiles\n^I    uplevel 1 [list ::source $file]\n^I} else {\n^I    # Pass along our configuration to the child processes.\n^I    # EXCEPT for the -outfile, because the parent process\n^I    # needs to read and process output of children.\n^I    set childargv [list]\n^I    foreach opt [Configure] {\n^I^Iif {[string equal $opt -outfile]} {continue}\n^I^Ilappend childargv $opt [Configure $opt]\n^I    }\n^I    set cmd [linsert $childargv 0 | $shell $file]\n^I    if {[catch {\n^I^Iincr numTestFiles\n^I^Iset" ..., length = 1458, flags = 0), line 3647 in "tclBasic.c"
    [63] TclEvalEx(interp = 0x100043e90, script = 0x1002c7d25 "if {[singleProcess]} {\n^I    incr numTestFiles\n^I    uplevel 1 [list ::source $file]\n^I} else {\n^I    # Pass along our configuration to the child processes.\n^I    # EXCEPT for the -outfile, because the parent process\n^I    # needs to read and process output of children.\n^I    set childargv [list]\n^I    foreach opt [Configure] {\n^I^Iif {[string equal $opt -outfile]} {continue}\n^I^Ilappend childargv $opt [Configure $opt]\n^I    }\n^I    set cmd [linsert $childargv 0 | $shell $file]\n^I    if {[catch {\n^I^Iincr numTestFiles\n^I^Iset" ..., numBytes = 1458, flags = 0, line = 1), line 4296 in "tclBasic.c"
    [64] Tcl_EvalEx(interp = 0x100043e90, script = 0x1002c7d25 "if {[singleProcess]} {\n^I    incr numTestFiles\n^I    uplevel 1 [list ::source $file]\n^I} else {\n^I    # Pass along our configuration to the child processes.\n^I    # EXCEPT for the -outfile, because the parent process\n^I    # needs to read and process output of children.\n^I    set childargv [list]\n^I    foreach opt [Configure] {\n^I^Iif {[string equal $opt -outfile]} {continue}\n^I^Ilappend childargv $opt [Configure $opt]\n^I    }\n^I    set cmd [linsert $childargv 0 | $shell $file]\n^I    if {[catch {\n^I^Iincr numTestFiles\n^I^Iset" ..., numBytes = 1458, flags = 0), line 4000 in "tclBasic.c"
    [65] TclExecuteByteCode(interp = 0x100043e90, codePtr = 0x100282690), line 1932 in "tclExecute.c"
    [66] TclObjInterpProcCore(interp = 0x100043e90, procNameObj = 0x10025ffb0, skip = 1, errorProc = 0x7fffffff7f59efe8 = &`libtcl8.5.so`tclProc.c`MakeProcError(Tcl_Interp *interp, Tcl_Obj *procNameObj)), line 1721 in "tclProc.c"
    [67] TclObjInterpProc(clientData = 0x100250f90, interp = 0x100043e90, objc = 1, objv = 0x10005d3d8), line 1615 in "tclProc.c"

    [68] TclEvalObjvInternal(interp = 0x100043e90, objc = 1, objv = 0x10005d3d8, command = 0x100237eca "tcltest::runAllTests\n", length = 21, flags = 0), line 3647 in "tclBasic.c"
    [69] TclEvalEx(interp = 0x100043e90, script = 0x100237bd0 "# 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 Scriptics Corporation.\n#\n# See the file "license.terms" for information on usage and redistribution\n# of this file, and for a DISCLAIMER OF ALL WARRANTIES.\n#\n# RCS: @(#) $Id: all.tcl,v 1.13 2007/12/13 15:27:54 dgp Exp $\n\npackage require Tcl 8.5\npackage require tcltest 2.2\npackage require Tk ;# This is the Tk test" ..., numBytes = 783, flags = 0, line = 22), line 4296 in "tclBasic.c"
    [70] Tcl_EvalEx(interp = 0x100043e90, script = 0x100237bd0 "# 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 Scriptics Corporation.\n#\n# See the file "license.terms" for information on usage and redistribution\n# of this file, and for a DISCLAIMER OF ALL WARRANTIES.\n#\n# RCS: @(#) $Id: all.tcl,v 1.13 2007/12/13 15:27:54 dgp Exp $\n\npackage require Tcl 8.5\npackage require tcltest 2.2\npackage require Tk ;# This is the Tk test" ..., numBytes = 783, flags = 0), line 4000 in "tclBasic.c"
    [71] Tcl_FSEvalFileEx(interp = 0x100043e90, pathPtr = 0x10005aff0, encodingName = (nil)), line 1826 in "tclIOUtil.c"
    [72] Tk_MainEx(argc = -1, argv = 0xffffffff7fffd328, appInitProc = 0x1000066c8 = &Tcl_AppInit(Tcl_Interp *interp), interp = 0x100043e90), line 272 in "tkMain.c"
    [73] main(argc = 4, argv = 0xffffffff7fffd308), line 68 in "tkAppInit.c"


tkt_uuid: 1854913fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5.7
resolution: Fixed
title: [.txt delete] deletes before startindex
comment:
  Consider following code:
    pack [text .t]
    .t insert end abcd\n
    .t delete 2.0 end

  One would expect that the delete operation would do nothing, since 2.0 is the end of the text. However, it deletes the newline *before* index 2.0.
  In interactive mode, this shows up as the <Delete> key deleting backwards when it's at the end of the text.

  The reason lies withing the DeleteIndexRange() function in tkText.c, which contains the following comment:
      /*
       * The code below is ugly, but it's needed to make sure there is always a
       * dummy empty line at the end of the text. If the final newline of the
       * file (just before the dummy line) is being deleted, then back up index
       * to just before the newline. If there is a newline just before the first
       * character being deleted, then back up the first index too, so that an
       * even number of lines gets deleted. Furthermore, remove any tags that
       * are present on the newline that isn't going to be deleted after all
       * (this simulates deleting the newline and then adding a "clean" one back
       * again). Note that index1 and index2 might now be equal again which
       * means that no text will be deleted but tags might be removed.
       */

  However, I really do not see the reason for the "...so that an even number of lines gets the deleted..." part. As if it shouldn't be possible to delete an odd number of lines!? I propose to remove that part of the comment (and the accompanying code). This fixes the bug, and I didn't see any adverse effects.


tkt_uuid: 1858063fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 78. Other Demos
priority: 5 Medium
foundin: None
resolution: Fixed
title: Goldberg demo fails at second call
comment:
  wish8.5 widget

  Start the new goldberg demo, the 4. entry under "Animation".
  Watch the demo, it's funny.
  Close the window.
  Try to start it again: ==> tcl error:

  can't set "S(speed)": invalid command name ".goldberg.start"


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

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


tkt_uuid: 1862340fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 30. Color Names
priority: 5 Medium
foundin: None
resolution: Later
title: systemMetalBackground produces black
comment:
  In the list of supported colors at http://www.tcl.tk/man/tcl8.4/TkCmd/colors.htm we have some Mac specific colors.

  systemModelessDialogBackgroundActive works fine and provides the Pinstripe texture, systemMetalBackground doesn't and provides black.

  Example:

  pack [::label .l -text "Hello world." -background systemMetalBackground]

  This is on Tcl/Tk 8.4.16 (Activestate release).


tkt_uuid: 1862692fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.0
resolution: Duplicate
title: ttk::treeview does not scroll up via mousewheel on OS-X
comment:
  using ActiveTcl 8.5 on OS-X Leopard x86, I can not scroll upwards via the mouse wheel. To reproduce, please try:

  package re Tk
  ttk::treeview .tv
  ttk::scrollbar .sb -command ".tv yview" -orient vert
  ..tv configure -yscrollcommand ".sb set"
  pack .tv .sb -side left -fill y
  for {set i 0} {$i < 100} {incr i} {
      .tv insert "" $i -text "node $i"
  }

  Then click inside the treeview and move the mouse wheel... normally (on Windows, Linux) the treeview is scrolled up and down, but my experience is that only the scrolling down works. This is only for ttk::treeview (as far as I see... text works) and for both, ttk::scrollbar and tk::scrollbar. So I suspect the troublemaker is ttk::treeview.


tkt_uuid: 1863007fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 8
foundin: obsolete: 8.5.0
resolution: Fixed
title: undefined symbol: ttkStubsPtr
comment:
  After compiling tileqt with -DUSE_TTK_STUBS, I get the error "undefined symbol: ttkStubsPtr" even though libtkstub8.5.a is included in the compile command.

  In the newsgroup Donal D. Fellows commented:

  At a guess (looking at win/Makefile.in without much thought) I'd say that ttkStubLib.o is getting packed into the wrong build library. A quick glance at the unix build file indicates that the same problem  seems to be there too.

  The thread:

  http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/2691af20c43a12b7/fa6cb486de155ae6?lnk=raot#fa6cb486de155ae6


tkt_uuid: 1863346fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4.16
resolution: Fixed
title: Aqua: SetPortPenPixPat leak
comment:
  This report is copied from a posting by Kevan Hashemi to the Tcl-Mac mailing list.

  The following script causes a 1 MByte/min leak in 8.4.16 on MacOS 
  10.4.10 Intel or PPC, but no leak in 8.4.14 or lower. The code deletes 
  the last line in a text widget and writes it over again.

  destroy .text
  set T [text .text -undo 0]
  pack $T
  proc display {} {
       global T
       $T delete "end -1 lines" end
       set s [clock format [clock seconds] -format {%c}]
       $T insert end $s
       after 10 display
  }
  display


tkt_uuid: 1863942fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5.0
resolution: None
title: Sizing trouble on tk_getOpenFile dialog
comment:
  Platform: Debian GNU/Linux testing on i386
  Window manager: fluxbox 1.0.0+deb1-4
  Tcl version: 8.5.0
  Tk version: 8.5.0

  Description:
  When a tk_getOpenFile dialog is open, it is open with a specific size and immediately get resized.
  Resizing make the file list so small that reading contents is unpossible.

  Comments:
  This happen more than 50% of the time (seems more often if I use ttk::label and ttk::button in below sample test code)


  If first dialog opening time is OK, it will always be OK.
  If first dialog opening time is not OK, it will always be not OK.
  See attached picture

  If I change window manager to icewm, it works fine all the time.

  I get the same issue with ActiveTcl installer at the time of choosing directories and with Tk widget.tcl demo when trying "File selection dialog" demo.

  Trouble has been reproduced with Debian , etcl-1.0-rc25, ActiveTcl8.5.0.0.283511-linux-ix86-threaded.
  Trouble did not happen with Tcl/Tk 8.4.16 (Debian) or tclkit8.5b1.

  LANG setting has no influence (tryed with fr_FR.UTF-8 and C)


  Sample test code:

  package require Tk

  set ::filename "File:"

  proc getFilename {} {
  set ::filename "File:"
  append ::filename [tk_getOpenFile -title "Choose a file"]
  }

  proc main {} {
  label .lblSelect -textvariable ::filename
  button .btnSelect -text "Click to select a file" -command { getFilename }
  pack .lblSelect -anchor w -side top
  pack .btnSelect -side top
  wm title . "Test of tk_getOpenFile"
  }

  main


tkt_uuid: 1864487fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.0
resolution: Duplicate
title: Accented characters appearing at the end of the line
comment:
  Whenever a Tcl/Tk program that has a text widget in it freezes, all input characters that have been typed with a dead key appear at the end of the line upon unfreezing of the program, regardless of where they were actually typed. Furthermore, all the characters that appear are equal to the last accented character typed.
  For example (assuming the acute and grave accents require dead keys for input): typing "déjà-vu" while the program is frozen, would result in "dj-vuàà" appearing upon unfreezing.

  I have found this bug in all versions of Tcl/Tk from at least 8.4.12 to the current 8.5.0.


tkt_uuid: 1864806fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4.17
resolution: Works For Me
title: Unexpected Aqua Edit menu/dialog sheet interaction
comment:
  Reproduced from my query to the Tcl-Mac mailing list:

  Attached is a script to reproduce an interface issue I encountered with TkAqua while working on a Tk application.

  I create a main menu bar containing menus and commands pertinent to my application. I follow an example from the Tcler's wiki (http://wiki.tcl.tk/12987#pagetoc21) to manually create an edit menu that works like the default menu bar.

  The problem I have encountered is that after a tk_getOpenFile dialog (and possibly others) is displayed as a sheet attached to the main window (via -parent .), the Cut, Copy, and Paste edit menu items appear disabled. Their keyboard shortcuts still work. Displaying the same dialog normally (without -parent .) does not have this result.

  The example below creates an edit menu in this fashion and provides an entry field where its function can be tested. Click 'Dialog' and dismiss the dialog; the edit menu items remain accessible. Click 'Sheet' and dismiss the dialog sheet; the edit menu items are disabled, but may still be invoked via their keyboard equivalents.

  Tested with 8.4.16 (tclkit-darwin-univ-aqua) and 8.4.17 (ActiveTcl Mac Tk basekit).


tkt_uuid: 1865898fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: Fixed
title: ttk::checkbutton doesn't show tristate on w2000
comment:
  On XP SP2 classic design or w2000 the tristate of ttk::checkbutton isn't shown.

  checkbutton .c1 -variable c1 -onvalue a \
      -offvalue b -tristatevalue c
  ttk::checkbutton .c2 -variable c2 -onvalue a \
      -offvalue b

  pack .c1 .c2 -side left

  set c1 a ;# .c1 checked with white background (on)
  set c1 b ;# .c1 unchecked with white background (off)
  set c1 c ;# .c1 checked with grey background (tristate)

  set c2 a ;# .c2 checked with white background (on)
  set c2 b ;# .c2 unchecked with white background (off)
  unset c2 ;# .c2 unchecked with white background (its the same like off)

  On XP SP2 with XP design:
  unset c2 ;# .c2 checked with fill-dot check (tristate) 

  It's tested with XP SP2 and ActiveState|eTcl
  and with w2000 SP4 and eTcl.

  The screenshot shows the tristate of both widgets on w2000.


tkt_uuid: 1866095fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 74. Application Embedding
priority: 9 Immediate
foundin: obsolete: 8.5.1
resolution: Fixed
title: TK_LIBS needs update
comment:
  When embedding Tk and linking to
  libtk.a, C programs need an updated
  value for TK_LIBS to be sure they
  link against the -lXft used by
  Tk 8.5.


tkt_uuid: 1867122fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 9 Immediate
foundin: obsolete: 8.5.0
resolution: Fixed
title: Crash in ttk::labelframe
comment:
  The following code crashes TCL-TK 8.5

  ttk::style layout WNtoolbar { Frame.border -sticky nswe }
  ttk::labelframe .toolbar1 -style WNtoolbar

  It worked in older versions


tkt_uuid: 1867834fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: ttk Toolbutton has wrong default anchor
comment:
  Create two buttons like this:

  package require Tk
  ttk::button .a \
      -text "Hello" \
      -width 10 \
      -style Toolbutton
  ttk::button .b \
      -text "World" \
      -width 10 
  pack .a .b

  On my windows XP machine the text of .a is left-
  justified but the text of .b is centered.

  The bug seems to be that the default anchor of the 
  Toolbutton style is left when it should be center. 
  I can fix this in my code with:

  ttk::style configure Toolbutton -anchor center

  I think the default for the Toolbutton should be
  centered, shouldn't it?


tkt_uuid: 1867897fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 8
foundin: obsolete: 8.5.0
resolution: Fixed
title: ttk::label truncates text on drawing
comment:
   package require Tk ; # using 8.5.0
   ttk::label .l -anchor nw -justify left -width 70
   pack .l -fill both
   .l configure -text "There is text\n
  \there is some more.\n
  jsdflkjsdlkfjlsdjflksdjlkj slfdjs dflkjsdflkj sd fsdlfkjsdflk sd fasldkjasd asd asdlkjasd asdlkj asdkjasldjasd lasjdalksjdasd asldjaslkdjasd laksjdlkajsd asldkjasd asldjasdlkjas dlkasjlkasjdlkasjd asdlkjasldkjasdlk alskdjalksdjalksdj asldkjasdlkjasd asldj"

  This only displays "There is text", although it makes some space for the other text.  If you use \n's to split the long line on <70char boundaries, all is displayed.

  This happens on X11 and Windows at least.


tkt_uuid: 1870330fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: None
priority: 5 Medium
foundin: None
resolution: None
title: Remove some Tk_Uid usage
comment:
  This patch cleans up some meaningless usages of Tk_Uid.

  If noone objects, I'll commit this some day.


tkt_uuid: 1871101fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 9 Immediate
foundin: obsolete: 8.5.0
resolution: Fixed
title: Vista Large DPI setting blurred
comment:
  Right Clicking on the Vista Desktop and activating the Personalize menu item provides access to the Personalization GUI. 

  There on the left hand side there is an entry Adjust font size (DPI). In the "Custom DPI..." Window setting, entering a value of 150% and not activating the "Use Windows XP style DPI scaling" causes all TK GUIs (8.4 and 8.5) to be blurred.

  I've provided an attachment from 8.5 showing the blurred 150% dpi.


tkt_uuid: 1871848fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 28. Utility Functions
priority: 5 Medium
foundin: None
resolution: Fixed
title: ::tk::UnderlineAmpersand reviewed
comment:
  the proc ::tk::UnderlineAmpersand  in tk.tcl
  seems to handle this case wrong:

  ::tk::UnderlineAmpersand "a&&a&b"
  a&ab 4

  So here is my patch (cvs, core-8-5-0 branch). It includes also an -exact option for a switch.


tkt_uuid: 1873592fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: None
resolution: Accepted
title: cascade menu does not work on linux or solaris
comment:
  when you make a popup menu, and add a cascade menu, the cascade menu items command does not get called when you click on them they even don't get activated when you move the mouse over them, the focus is always with the main menu, I'm using Tcl/Tk 8.5.0.

  menu .sub
  .sub add command -command "puts sub_menu" -label subItem
  menu .top
  .top add command -command "puts top_menu" -label topItem
  .top add cascade -label sub -menu .sub
  tk_popup .top 100 100


tkt_uuid: 1873627fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
foundin: None
resolution: None
title: Column separator in ttk::treeview
comment:
  Having tested the ttk::treeview I lack one
  visual thing.  A column separator line.
  A thin line in a different color between columns
  would help the eye a lot.
  Maybe have it configurable per column if a
  separator should be visible.


tkt_uuid: 1874578fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 81. Portability
priority: 5 Medium
foundin: None
resolution: None
title: Configure fails to find dirent64 on CentOS 5 and Fedora
comment:
  Tk, both shipping with Cent OS 5, and when built from the www.tcl.tk
  source files fails to glob 64bit NFS file shares. Looking at the output of
  configure this is due to it failing to find dirent64.

  Behaviour:

  Mount an NFS share from a 64bit file server, eg Mac OS X 10.4 serving out a
  11TB volume.
  wish
  cd /mylargevolume
  set files [glob "*"]

  gives the error, 'no files matched glob pattern "*"'

  Looking at tcl.m4, autoconf is looking for 'struct dirent64' in
  <sys/dirent.h>, however on Cent OS (RHEL 5) this file doesn't exist. The
  'dirent64' structure is defined in /usr/include/dirent.h, so modifying
  tcl.m4 to '#include <dirent.h>' allows configuration to complete correctly
  and the built binaries ARE able to glob the directory structure on the NFS
  share.

  This bug is equivalent to bug #1874521 in the TCL bug tracker. 

  The patch provided there doesn't work with tk, 
  configure:7469: checking for struct dirent64
  configure:7493: gcc -pipe -c   conftest.c >&5
  conftest.c:32:24: error: sys/dirent.h: No such file or directory
  configure:7499: $? = 1
  configure: failed program was:
  | /* confdefs.h.  */
  | 
  | #define PACKAGE_NAME ""
  | #define PACKAGE_TARNAME ""
  | #define PACKAGE_VERSION ""
  | #define PACKAGE_STRING ""
  | #define PACKAGE_BUGREPORT ""
  | #define STDC_HEADERS 1
  | #define HAVE_SYS_TYPES_H 1
  | #define HAVE_SYS_STAT_H 1
  | #define HAVE_STDLIB_H 1
  | #define HAVE_STRING_H 1
  | #define HAVE_MEMORY_H 1
  | #define HAVE_STRINGS_H 1
  | #define HAVE_INTTYPES_H 1
  | #define HAVE_STDINT_H 1
  | #define HAVE_UNISTD_H 1
  | #define HAVE_LIMITS_H 1
  | #define HAVE_UNISTD_H 1
  | #define USE_THREAD_ALLOC 1
  | #define _REENTRANT 1
  | #define _THREAD_SAFE 1
  | #define HAVE_PTHREAD_ATTR_SETSTACKSIZE 1
  | #define HAVE_PTHREAD_ATFORK 1
  | #define TCL_THREADS 1
  | #define PEEK_XCLOSEIM 1
  | #define _LARGEFILE64_SOURCE 1
  | #define TCL_WIDE_INT_TYPE long long
  | /* end confdefs.h.  */
  | #include <sys/types.h>
  | #include <dirent.h>
  | #include <sys/dirent.h>
  | int
  | main ()
  | {
  | struct dirent64 p;
  |   ;
  |   return 0;

  appears in config.log. This doesn't occur for tcl, but I'm unsure why, as clearly <sys/dirent.h> doesn't exist in either case.


  duncan@fmrib.ox.ac.uk


tkt_uuid: 1876493fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: obsolete: 8.5.0
resolution: Fixed
title: Standard option -state not documented
comment:
  The -state option is not documented on the standard options page (http://www.tcl.tk/man/tcl8.5/TkCmd/options.htm), although for example [ttk::checkbutton]'s man page (http://www.tcl.tk/man/tcl8.5/TkCmd/ttk_checkbutton.htm) links to it.


tkt_uuid: 1876768fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: None
resolution: None
title: fix for bug 220826 - reentrancy and tk_messageBox
comment:
  The bug 220826 is currently marked as close, but shouldn't have been closed IMHO.

  This patch makes the common variable used by the dialog box unique per dialog box window.  This prevents the global close of all currently active dialog boxes exhibited by the bug report.

  It does not change the current behavior that causes a subsequent dialog to close the currently active dialog that has the same parent window name.

  The change is simple enough to replicate on the 8.4 branch.

  The attached tar file contains diffs of files msgbox.tcl dialog.tcl and dialog.test.


tkt_uuid: 1878298fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.0
resolution: Fixed
title: ttk::notebook not showing new tabs
comment:
  The ttk::notebook widget doesn't properly display new
  tabs when inserted at end.
  Generating an <Expose> event after the insertion
  workarounds the problem.


  set i 0
  ttk::notebook .nb
  text .nb.txt
  .nb insert end .nb.txt -text Initial

  pack .nb -expand 1 -fill both

  bind all <Control-t> {
  text .nb.txt$i
  .nb insert end .nb.txt$i -text "Insert $i"
  #this line workarounds the problem
  #event generate .nb <Expose>
  incr i
  }


tkt_uuid: 1881892fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: obsolete: 8.5.0
resolution: Fixed
title: Incorrect default title for tk_messageBox on Windows
comment:
  The default title if you don't specify a "-title" is "Error", whereas according to the manual page (and other platforms) it should be the empty string.


tkt_uuid: 1881896fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: obsolete: 8.5.0
resolution: Fixed
title: Updates for tk_messageBox manual pages.
comment:
  1. Man page should note that the "-title" option (correctly, according to the HIG) has no effect on Mac OS X.

  2. Because all of Windows, Mac OS X and X11 now do display the secondary message provided by the "-detail" option, the "Where supported by the underlying OS" caveat should be removed.


tkt_uuid: 1881903fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 38. [tk_messageBox]
priority: 6
foundin: obsolete: 8.5.0
resolution: None
title: tk_messageBox -icon on Mac wrong
comment:
  This was using ActiveTcl anyway.

  1. calling tk_messageBox with no icon on Mac OS X results in no icon in the dialog; according to manual pages (and other platforms) it should show the "info" icon

  2. "-icon question" shows the "warning" icon

  3. "-icon error" shows the application (info) icon


tkt_uuid: 1881923fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.0
resolution: None
title: wm geometry with negative positions wrong
comment:
  Specifying a negative x/y position in "wm geometry" does not behave correctly.

  e.g. "wm geometry . -20-20"

  The correct behavior should be that the right/bottom edges of the window will each be 20 pixels from the bottom right corner of the screen. This is what happens on Windows and X11.

  When I try it on Mac OS X,  the window is mostly offscreen, with just the top left corner peaking out from the bottom right of the screen.


tkt_uuid: 1882011fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.0
resolution: Fixed
title: reorder ttk_notebook man page
comment:
  The section labelled 'Identifiers' should appear before the 'Widget Command' section, since it defines the 'tabid' used by most of the widget commands.

  That would be consistent with e.g. the canvas man page which defines 'tagorid' before it is used.

  Clearly a show stopper. ;-)


tkt_uuid: 1882495fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: obsolete: 8.5.0
resolution: Fixed
title: Undocumented "standard" options
comment:
  The following "standard" options are undocumented:

  canvas.n: -state
  listbox.n: -activestyle
  listbox.n: -height
  listbox.n: -state
  listbox.n: -width
  message.n: -width
  panedwindow.n: -height
  panedwindow.n: -width


tkt_uuid: 1883418fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: None
resolution: Fixed
title: negative button width not documented
comment:
  On Windows, a button can be created/configured with a negative width, which specifies a mimimum value for the width. It seems this is not documented.


tkt_uuid: 1883850fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: xptheme appearance on Vista
comment:
  USCode reports on c.l.t:

  I've been using Vista for a few months now and have noticed a few cosmetic differences.  I have a Vista machine on my left and an XP machine on my right so it's easy to compare.

  What I've noticed so far:

  - Combobox: When the box is 'readonly' (not enterable, user must select from defined list) the box assumes a different shape and color/texture altogether.

  - Indeterminate progress bar - the indeterminate indicator is wider and sort of fuzzed out on the ends.


tkt_uuid: 1884664fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: None
title: resolve confusion between apple and application menus
comment:
  Because in aqua we're actually modifying the application menu and not the apple menu (which we don't touch), it's confusing that the menu must still have a pathname of "*.apple".

  The current documentation does note that it is the application menu that is being modified, but it may be useful to draw some more attention to the discrepancy.

  Longer-term, it would be nice to see this changed from ".apple" to ".application".  Perhaps this is something to keep in mind if/when a ttk version of menus gets created.


tkt_uuid: 1884667fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Wont Fix
title: search broken in help menu on leopard
comment:
  If you add a help menu on Leopard, it automatically contains a search box; however, you can't type into it at all, which certainly leaves the impression the program isn't working right.


tkt_uuid: 1884782fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.4.7
resolution: None
title: simple Tk app to display data crashes wish
comment:
  A developer contacted me asking me for help. He had data in a Chinese encoding that he needed to display in a Tcl/Tk application. After asking on the wiki and comp.lang.tcl, it appears that Tcl doesn't support this encoding. It was recommended that he use iconv to convert the encoding into one that is supported.
  He did so, then, with the following application, attempted to display the data. Note that when _I_ run this script, I get the chinese output as expected. When he runs it, he gets a Bus error core dump on SPARC Solaris 9... This is with a standard Tcl interpreter.

  Okay, here's the application:

     package require Tk
     frame .f
     text .text -bg white -wrap word 
   
     pack .f -side top
     pack .text -side left -expand true -fill both
   
     .text configure -font "helvetica-22"
   
     .text delete 1.0 end
   
      set f [open "~/foo.utf8" "r"]
      fconfigure $f -encoding "utf-8"
      set buf [read $f 32000]
   
      .text insert end $buf
   
      close $f

  I will attempt to attach the foo.utf8 to this ticket.

  Note that while the original report of this problem is from Tcl/Tk 8.4.7 - the developer reports seeing the same problem with 8.5.0. However, I don't have the stack trace from the tcl/tk 8.5 attempt - just this one.
  The stack trace is:
   $ dbx -f /usr/tcl84/bin/tclsh core
  For information about new features see `help changes'
  To remove this message, put `dbxenv suppress_startup_message 7.0' in your .dbxrc
  Reading tclsh
  core file header read successfully
  Reading ld.so.1
  Reading libtcl8.4g.so
  Reading libdl.so.1
  Reading libsocket.so.1
  Reading libnsl.so.1
  Reading libm.so.1
  Reading libc.so.1
  Reading libmp.so.2
  Reading libc_psr.so.1
  Reading libtk8.4g.so
  Reading libX11.so.4
  Reading libXext.so.0
  program terminated by signal BUS (invalid address alignment)
  Current function is Tcl_UtfToUniChar
    338                       | ((str[1] & 0x3F) << 6) | (str[2] & 0x3F));
  (dbx 1) where                                                         
  =>[1] Tcl_UtfToUniChar(str = 0xffbfdaad "\xe5\x80\x80\xff\xbf\xdc\x9c", chPtr = 0xffbfda9d), line 338 in "tclUtf.c"
    [2] UtfToUcs2beProc(clientData = (nil), src = 0xffbfdaad "\xe5\x80\x80\xff\xbf\xdc\x9c", srcLen = 3, flags = 7, statePtr = 0xffbfd9c4, dst = 0xffbfda9d "", dstLen = 14, srcReadPtr = 0xffbfd9d0, dstWrotePtr = 0xffbfd9cc, dstCharsPtr = 0xffbfd9c8), line 616 in "tkUnixFont.c"
    [3] Tcl_UtfToExternal(interp = (nil), encoding = 0x3e950, src = 0xffbfdaad "\xe5\x80\x80\xff\xbf\xdc\x9c", srcLen = 3, flags = 7, statePtr = 0xffbfd9c4, dst = 0xffbfda9d "", dstLen = 14, srcReadPtr = 0xffbfd9d0, dstWrotePtr = 0xffbfd9cc, dstCharsPtr = 0xffbfd9c8), line 1093 in "tclEncoding.c"
    [4] FontMapLoadPage(subFontPtr = 0xffbfdc9c, row = 20), line 2097 in "tkUnixFont.c"
    [5] FontMapLookup(subFontPtr = 0xffbfdc9c, ch = 21457), line 1985 in "tkUnixFont.c"
    [6] CanUseFallback(fontPtr = 0xc91e8, faceName = 0xc3978 "fixed", ch = 21457, fixSubFontPtrPtr = (nil)), line 2429 in "tkUnixFont.c"
    [7] FindSubFontForChar(fontPtr = 0xc91e8, ch = 21457, fixSubFontPtrPtr = (nil)), line 1858 in "tkUnixFont.c"
    [8] Tk_MeasureChars(tkfont = 0xc91e8, source = 0xc96a4 "<\xe5\x8f\x91\xe6\x98\x8e\xef\xbc\x88\xe8\xae\xbe\xe8\xae\xa1\xef\xbc\x89\xe4\xba\xba>=\xe5\x89\x8d,\xe6\xbb\x9d,\xe8\xbf\x9b\n", numBytes = 35, maxLength = 560, flags = 0, lengthPtr = 0xffbfe08c), line 1051 in "tkUnixFont.c"
    [9] MeasureChars(tkfont = 0xc91e8, source = 0xc96a4 "<\xe5\x8f\x91\xe6\x98\x8e\xef\xbc\x88\xe8\xae\xbe\xe8\xae\xa1\xef\xbc\x89\xe4\xba\xba>=\xe5\x89\x8d,\xe6\xbb\x9d,\xe8\xbf\x9b\n", maxBytes = 36, startX = 0, maxX = 560, tabOrigin = 0, nextXPtr = 0xffbfe124), line 5216 in "tkTextDisp.c"
    [10] TkTextCharLayoutProc(textPtr = 0x31500, indexPtr = 0xffbfe20c, segPtr = 0xc9698, byteOffset = 0, maxX = 560, maxBytes = 36, noCharsYet = 1, wrapMode = TEXT_WRAPMODE_WORD, chunkPtr = 0x3a198), line 4485 in "tkTextDisp.c"
    [11] LayoutDLine(textPtr = 0x31500, indexPtr = 0xffbfe2d4), line 1007 in "tkTextDisp.c"
    [12] UpdateDisplayInfo(textPtr = 0x31500), line 1321 in "tkTextDisp.c"
    [13] TkTextPixelIndex(textPtr = 0x31500, x = 0, y = 0, indexPtr = 0xffbfe42c), line 4139 in "tkTextDisp.c"
    [14] TkTextPickCurrent(textPtr = 0x31500, eventPtr = 0x316b4), line 1411 in "tkTextTag.c"
    [15] DisplayText(clientData = 0x31500), line 2248 in "tkTextDisp.c"
    [16] TclServiceIdle(), line 704 in "tclTimer.c"
    [17] Tcl_DoOneEvent(flags = -3), line 955 in "tclNotify.c"
    [18] Tk_MainLoop(), line 1500 in "tkEvent.c"
    [19] Tcl_Main(argc = 1, argv = 0xffbfe8c0, appInitProc = 0x10820 = &Tcl_AppInit(Tcl_Interp *interp)), line 485 in "tclMain.c"
    [20] main(argc = 2, argv = 0xffbfe8bc), line 90 in "tclAppInit.c"
  (dbx 2) 


tkt_uuid: 1884975fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.5.0
resolution: None
title: Bindings not created for a TK app on linux
comment:
  If you build and run the attached program (tkw.cxx) on Linux with version 8.5.0 then the number of bindings displayed for the listbox is incorrectly 0.

  The same program builds and runs correctly on version 8.5.0 on WinXP and 8.4.16 on Linux. The script tkw.tcl runs correctly when run as a script.

  Files:
  Makefile - edit for your setup
  tkw.cxx  - simple C++ program
  tkw.tcl  - the test script


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

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

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

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


tkt_uuid: 1887169fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: Accepted
title: small error in menu.n about windows system menu
comment:
  The phrase "This menu has an icon representing a spacebar" is incorrect (well, it was correct before windows 95!).  It's actually the application icon.


tkt_uuid: 1887171fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: None
resolution: Duplicate
title: help menu should not be right justified
comment:
  While it should continue to be the last menu, having it right justified in the menubar is a holdover from Motif... systems like KDE and Gnome don't do that anymore


tkt_uuid: 1892159fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: None
resolution: Rejected
title: Add message catalog information for months and days of weeks
comment:
  http://wiki.tcl.tk/1816 is a internationalized date chooser megawidget. Within the code is a series of message catalog entries for the month names, day of week names, etc.

  It would be beneficial to at least ensure that all of these were available from tk. It would even be nicer if a date selector megawidget similar to this one were available as either a widget demo or as a usable widget in the Tk distribution.


tkt_uuid: 1893950fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 8
foundin: obsolete: 8.5.1
resolution: Duplicate
title: Update menu cascade behavior
comment:
  The behavior of cascade menus on Unix/Linux needs to be updated to match common tools like the Mozilla based tools.  Cascade menus should post as soon as the mouse rolls over the item.  Currently, Tk menus do this but only if the mouse button is down.  The following change in menu.tcl will affect this behavior for the better.

  proc ::tk::MenuMotion {menu x y state} {
      variable ::tk::Priv
      set docascade 1
      if {$menu eq $Priv(window)} {
  if {[$menu cget -type] eq "menubar"} {
      if {[info exists Priv(focus)] && $menu ne $Priv(focus)} {
  $menu activate @$x,$y
  GenerateMenuSelect $menu
  if {$Priv(focus) eq ""} {
      set docascade 0
  }
      } else {
  set docascade 0
      }
  } else {
      $menu activate @$x,$y
      GenerateMenuSelect $menu
  }
      }
      if {$docascade} {
  $menu postcascade active
      }
  }

  -Brian


tkt_uuid: 1894038fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 9 Immediate
foundin: obsolete: 8.5.1
resolution: Fixed
title: pkgIndex.tcl filter is too strict AND too lax
comment:
  When Tk 8.5.1 is built and installed
  from the source code distribution, the
  pkgIndex.tcl file that gets installed
  contains:

  if {[catch {package present Tcl 8.5.1}]} { return }
  package ifneeded Tk 8.5.1       [list load [file join $dir .. libtk8.5.so] Tk]


  This script means that in an 8.5.0 Tcl interp,
  the command

    package require -exact Tk 8.5.1

  will fail, even though the corresponding
  [load] would work just fine.  Tk 8.5.1 is
  perfectly compatible with Tcl 8.5.0.

  It seems that replacing the "$(TCLPATCHL)"
  on line 710 of tk/unix/Makefile.in with
  the literal string ".0" would resolve this.


tkt_uuid: 1898288fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 02. Appearance
priority: 5 Medium
foundin: None
resolution: Fixed
title: Sash width option in ttk::panedwindow
comment:
  The standard Tk panedwindow has a -sashwidth option that would also be very handy for the ttk::panedwindow sash.

  Many modern applications are going to thin 1 or 2 pixel sashes (see iTunes, Windows Mail on Vista, etc.) and this option would allow a ttk::panedwindow to emulate this appearance.

  (Ideally, being able to set the ttk::panedwindow sash -background color of the sash would also be very useful as well but I would prioritize the -sashwidth option first.)

  Thanks Joe!


tkt_uuid: 1899040fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 15. [scale]
priority: 5 Medium
foundin: obsolete: 8.5.1
resolution: None
title: TkRoundToResolution doesn't account for -from
comment:
  If you run the following script you get a scale that can be set to the values of -1, 0, 1, and 2.  I would argue that for consistency the values should be at -1.5, -.5, .5, and 1.5.  

  toplevel .test
  pack [scale .test.s -orient horizontal]
  .test.s configure -resolution 1 -from -1.5 -to 1.5


  This behavior is in both 8.4.x and 8.5.x.

  The problem is that TkRoundToResolution function doesn't take into account the -from value.


  The following patch provides the expected behavior.  It rounds to the resolution value in terms of units relative to the -from value:


  RCS file: /projects/cvs/slicer/tk/generic/tkScale.c,v
  retrieving revision 1.1.1.1
  diff -r1.1.1.1 tkScale.c
  1148a1149
  >     value = value + scalePtr->fromValue;
  1160a1162
  >     new = new - scalePtr->fromValue;


  The entire function, including the patch, is here:


  double
  TkRoundToResolution(scalePtr, value)
      TkScale *scalePtr;    /* Information about scale widget. */
      double value;   /* Value to round. */
  {
      double rem, new, tick;

      if (scalePtr->resolution <= 0) {
    return value;
      }
      value = value + scalePtr->fromValue;
      tick = floor(value/scalePtr->resolution);
      new = scalePtr->resolution * tick;
      rem = value - new;
      if (rem < 0) {
    if (rem <= -scalePtr->resolution/2) {
        new = (tick - 1.0) * scalePtr->resolution;
    }
      } else {
    if (rem >= scalePtr->resolution/2) {
        new = (tick + 1.0) * scalePtr->resolution;
    }
      }
      new = new - scalePtr->fromValue;
      return new;
  }


tkt_uuid: 1899664fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 76. Widget Tour
priority: 5 Medium
foundin: obsolete: 8.5.1
resolution: Fixed
title: Goldberg script fails on a second launch
comment:
  OS: WindowsXP Pro. SP2
  TclTk: ActiveTcl8.5.1.0.284069-win32-ix86-threaded.exe

  1) start the Tk Demo (widget.tcl)
  2) launch the demo: A celebration of Rube Goldberg
  3) close that demo window
  4) again, open the demo: A celebration of Rube Goldberg
  (without closing and reopening the main demo window)

  On the last step an error appears:
  ------------------------------
  can't set "S(speed)": invalid command name ".goldberg.start"
  invalid command name ".goldberg.start"
      while executing
  "$w.start  config -state $z([expr {$m != $::MGO}])"
      (procedure "ActiveGUI" line 7)
      invoked from within
  "ActiveGUI S speed w"
      (write trace on "S(S)")
      invoked from within
  "set S(speed) 5"
      (file "D:/UTIL/Tcl/demos/Tk8.5/goldberg.tcl" line 69)
      invoked from within
  "source D:/UTIL/Tcl/demos/Tk8.5/goldberg.tcl"
      ("uplevel" body line 1)
      invoked from within
  "uplevel 1 [list source [file join $tk_demoDirectory $demo.tcl]]"
      (procedure "invoke" line 12)
      invoked from within
  "invoke [.t index {@149,478}]"
      (command bound to event)
  ------------------------------

  it seams that goldberg.tcl sets several "traces" and doesnot "remove" them on "destroying" the window

  I attach a modified demo file,
  with "trace remove ..." added
  It launches as many times as one wishes.


tkt_uuid: 1900872fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: None
title: makefile.vc needs ws2_32.lib added to baselibs
comment:
  When compiling with Visual C++ 2008 the definition of baselibs in makefile.vc must be changed to the following in order to link the WISH program properly.

  baselibs   = kernel32.lib user32.lib ws2_32.lib


tkt_uuid: 1904322fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5.1
resolution: Fixed
title: multiple selection problem
comment:
  tk_getOpenFile -multiple 1 on Tk8.5.1 fails to select multiple files; it seems as if they were concatenated into one filename which doesn`t exist.


tkt_uuid: 1905656fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Invalid
title: Asking the width of a textwidget don't work like expected.
comment:
  The following code returns allways the same value (80) for '.t cget -width' even after resizing the window:

   text .t
   pack .t -fill both -expand 1
   update
   wm geometry .       ;# returns 644x388 ...
   .t cget -width      ;# returns 80
   .t configure -width ;# returns -width width Width 80 80

   .t insert end [string repeat a 200]
   update
   wm geometry .       ;# returns 644x388 ...
   .t cget -width      ;# returns 80
   .t configure -width ;# returns -width width Width 80 80


   # resize window with mouse
   update
   wm geometry .       ;# returns 644x388 ...
   .t cget -width      ;# returns 80
   .t configure -width ;# returns -width width Width 80 80

   wm geometry . 1000x500
   update
   wm geometry .       ;# returns 1000x500
   .t cget -width      ;# returns 80
   .t configure -width ;# returns -width width Width 80 80

  On the other side: Modifying the width with -width works:

   text .t
   pack .t -fill both -expand 1
   update
   wm geometry .       ;# returns 644x388 ...
   .t cget -width      ;# returns 80
   .t configure -width ;# returns -width width Width 80 80

   .t insert end [string repeat a 200]
   update
   wm geometry .       ;# returns 644x388 ...
   .t cget -width      ;# returns 80
   .t configure -width ;# returns -width width Width 80 80

   .t configure -width 120
   update
   wm geometry .       ;# returns 964x388 ...
   .t cget -width      ;# returns 120
   .t configure -width ;# returns -width width Width 80 120

   .t configure -width 80
   update
   wm geometry .       ;# returns 644x388 ...
   .t cget -width      ;# returns 80
   .t configure -width ;# returns -width width Width 80 80


  I tried this with ActiveTcl 8.5.1.0, ETcl 1.0-rc25 und Etcl 1.0-rc23. This means this happens on Tcl 8.4 and 8.5.
   


tkt_uuid: 1906768fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: None
title: data -grayscale returning all black
comment:
  Using '$img data -grayscale' returns all black. Here's sample code:

  set ifile [file join $tk_library demos images earth.gif]
  set org [image create photo -file $ifile]
  set bug [image create photo]
  $bug put [$org data -grayscale]
  label .org -image $org -text org -compound top -bg red -bd 2 -relief ridge
  label .bug -image $bug -text bug -compound top -bg cyan -bd 2 -relief ridge
  pack .org .bug -side left


tkt_uuid: 1908284fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 39. Image Basics
priority: 5 Medium
foundin: obsolete: 8.5.1
resolution: Duplicate
title: Aqua: SetPortPenPixPat() Leak in TkPhotoPutBlock
comment:
  My TclTk extension calls TkPhotoPutZoomedBlock. On Linux and Windows, when I call the routine 10,000 times, I get no significant increase in memory consumption. I can say with confidence that the leakage per call is less than 50 bytes (and is most likely zero).

  On MacOS, however, I see a roughly 650-byte (+-50 bytes) increase in memory consumption per call to TkPhotoPutZoomedBlock. When I switch to TkPhotoPutBlock, the increase drops to around 300 bytes (+-50 bytes).

  I get the same leak with TclTk 8.4.16 and TclTk 8.5.1. 

  The following script, which I believe calls TkPhotoPutBlock or TkPhotoPutZoomedBlock, generates a 525-byte (+-50 bytes) leak per iteration.

  -------------
  set p [image create photo]
  label .l -image $p
  pack .l
  for {set i 1} {$i <= 1000} {incr i} {
  $p read ~/Desktop/An_Image.gif -format GIF
  }
  image delete $p
  destroy .l
  --------------

  I conclude that the MacOS implementation of both routines is leaky. The result is that my MacOS code will crash after three days of continuous data-taking.

  Kevan Hashemi


tkt_uuid: 1908443fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: obsolete: 8.5.1
resolution: Fixed
title: Composed characters in UTF-8 locale
comment:
  Observed on Debian Sarge after installing UTF-8 locales: ISO8859-1 characters entered with compose key sequences end up wrong.

  Setup: xmodmap -e 'keysym Super_L = Multi_key Super_L'
  (this makes the Windows key into a Compose key).
  export LC_ALL=en_US.UTF-8
  export XMODIFIERS=@im=local

  Run wish; verify that [encoding system] is utf-8
  Press e.g., <Compose> <c> <comma>.  
  This should turn into ç (c-cedilla, \UE7).  Instead, it shows up as \UFFE7.

  I think I've narrowed this down to sometime between 8.4.12 and 8.4.13.  Problem appears to be in Tcl, not Tk.

  This looks like improper sign extension.


tkt_uuid: 1909931fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 5 Medium
foundin: obsolete: 8.5.1
resolution: Fixed
title: send and xauth problem on Fedora 8
comment:
  [send] doesn't work on Fedora 8 with stock setup due to the auth setup checks [send] does.

  There was a bug filed against Fedora regarding this issue: https://bugzilla.redhat.com/show_bug.cgi?id=349071 which was closed with the resolution "not a bug" and the explanation attached from which it's clear that Fedora is not about changing its policy regarding X auth setup. This implies [send] will continue not to work properly on future versions of Fedora (and who knows -- may be RHEL also).

  I'm not an expert in X auth so it would be cool if someone with enough expertise in this field analyzed the situation -- may be [send] worth fixing to lax its rules regarding checking of X auth settings or so.


tkt_uuid: 1911011fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 76. Widget Tour
priority: 5 Medium
foundin: obsolete: 8.5.1
resolution: Postponed
title: cscroll.tcl MouseWheel scrolling only works on Mac
comment:
  Hi guys.

  I was hoping to use the cscroll.tcl demo to sort out why the scrollframe by Ulis at http://wiki.tcl.tk/9223 (a similar canvas implimentation) wasn't accepting and acting on MouseWheel events.

  However, on testing with both X11 and Windows, the Tk demo cscroll.tcl's MouseWheel events are only acted on if the platform is Mac (Aqua). Elsewhere, MouseWheel events are ignored.


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

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


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


tkt_uuid: 1912679fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.5.1
resolution: Fixed
title: chmod error during tk cvs head install
comment:
  I downloaded the cvs head tar files from activestate's ftp site.

  I built and installed tcl on my sparc solaris 9 system, using sun's c compiler.

  I build tk next. When I did the gmake install, I get

  Installing libtkstub8.5.a to /projects/sprs_lwv/tcl85/lib/
  Making directory 
  usage:  chmod [-fR] <absolute-mode> file ...
          chmod [-fR] <symbolic-mode-list> file ...
  where   <symbolic-mode-list> is a comma-separated list of
          [ugoa]{+|-|=}[rwxXlstugo]

  To try and figure out what is going wrong here, I removed the @ before the if statement. Here's what I see when I run it again:
  Installing libtkstub8.5.a to /projects/sprs_lwv/tcl85/lib/
  if test "" != ""; then \
              XLIB_INCLUDE_INSTALL_DIR="/projects/sprs_lwv/tcl85/include"/X11; fi; \
          for i in "/projects/sprs_lwv/tcl85/include" "${XLIB_INCLUDE_INSTALL_DIR}" \
                  "/projects/sprs_lwv/tcl85/lib/tk8.5" "/projects/sprs_lwv/tcl85/lib/tk8.5"/images \
                  "/projects/sprs_lwv/tcl85/lib/tk8.5"/msgs "/projects/sprs_lwv/tcl85/lib/tk8.5"/ttk; \
              do \
              if [ ! -d "$i" ] ; then \
                  echo "Making directory $i"; \
                  mkdir -p "$i"; \
                  chmod 755 "$i"; \
                  else true; \
                  fi; \
              done;
  Making directory 
  usage:  chmod [-fR] <absolute-mode> file ...
          chmod [-fR] <symbolic-mode-list> file ...
  where   <symbolic-mode-list> is a comma-separated list of
          [ugoa]{+|-|=}[rwxXlstugo]

  I am uncertain why, but the only thing I can figure is that the XLIB_INCLUDE_INSTALL_DIR is ending up null, despite being set...


tkt_uuid: 1913251fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 7 High
foundin: None
resolution: Works For Me
title: default menu keyboard binding Aqua inconsistencies
comment:
  The default bindings for Tk menus include the use of arrow keys to navigate menus and return or the space bar to invoke the selected item 9http://www.tcl.tk/man/tcl8.5/TkCmd/menu.htm#M77). These bindings do not seem to work with Tk Aqua on Mac OS X 10.5 (I cannot confirm whether this applies to Mac OS X 10.4 as well).

  Attached is a simple script which creates a pair of menus containing dummy items and a submenu. In X11 and Windows, I can change the selected menu item with the up and down arrows and change menus with the left and right arrows. (If the submenu item is selected, the right arrow shows the cascade menu.) Pressing the space bar or return selects the items and unposts the menu.

  These commands do not seem to do anything with Tk Aqua. This is noticeable because most Mac OS X applications do permit keyboard navigation with the arrows.

  The specific versions I've tested are listed here. Keyboard navigation does not work as expected in the Aqua combinations but does in the other two.

  8.5.0  Aqua Mac OS X 10.5.2
  8.4.17 Aqua Mac OS X 10.5.2
  8.5.1  X11 Mac OS X 10.5.2
  8.5.1  Windows Server 2003


tkt_uuid: 1913750fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.10
resolution: Fixed
title: tk_chooseDirectory -initialdir internationalization problem
comment:
  The problem can be observed when we use the Japanese name for the folder name.

  For example:

  tk_getOpenFile -initialdir [file join $env(HOME) "テスト"]

  This works fine, the dialog opens $env(HOME)/テスト

  "テスト" is a folder written in Japanese.

  However,

  tk_chooseDirectory -initialdir [file join $env(HOME) "テスト"]

  This does not work properly.

  The dialog does not indicate $env(HOME)/テスト but indicates $env(HOME) and a part of "テスト" is ignored.

  This problem can be observed on Windows version of Tcl/Tk.
  On UNIX version, this may not be observed, at least on Fedora 8, there seems no problem, it works fine. Thanks.

  Keiichi


tkt_uuid: 1913825fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.18
resolution: Works For Me
title: tk_getOpenFile freezes after internal filedialog was in use
comment:
  Hello,

  on Aqua (Tiger) the tk_getOpenFile dialog freezes wish if
  the internal file dialog (::tk::dialog::file:: open)
  was in use before.
  To reproduce, start wish, then type:
  > ::tk::dialog::file:: open
  (select cancel)
  > tk_getOpenFile -parent .
  (click on your home, or browse around, wish freezes
  sooner or later).

  The -parent option is important to trigger the freeze!

  best regards,
  Randolf


tkt_uuid: 1916280fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.1
resolution: Duplicate
title: text widget large load and scrollbar weirdness
comment:
  The following script demonstrates weirdness in 8.5
  with the scrollbar wherein a large load appears normally
  (as in 8.4/3), BUT if <Control-1> is used in the middle of the scrollbar, the scrollbar continuously adjusts
  for 45 seconds as though a load is still in progress.  

  However, using <Control-Next>, to immediately go to EOF shows that all the data is already loaded.

  (Tested on Linux i86 and x64)

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

  text .n -yscrollcommand ".s set"
  pack [scrollbar .s -command ".n yview"] -fill y -side left
  pack .n -fill both -expand y -side left
  .n conf -tabs {20 120}
  for {set i 0} {$i<10000} {incr i} {
      set nn [.n insert end "\tNODE $i\n"]
          for {set j 0} {$j<10} {incr j} {
              .n insert end "\t  SUBNODE $i.$j\n"
          }
  }


tkt_uuid: 1917674fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Select font in wish console
comment:
  Added some code to console.tcl to allow setting the font from a select list of font families in the edit menu.


tkt_uuid: 1919570fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 01. Bindings
priority: 6
severity: Minor
foundin: None
resolution: Fixed
title: MacOSX entry bindings
comment:
  MacOSX has some behaviour that is different than current tk/ttk for Entry and TEntry widgets. There might be additional bindings with modifiers, but don't know how established these are.

  The following bindings should either replace existing or added. This applies to Entry and TEntry widgets.


      if {[tk windowingsystem] eq "aqua"} {

  # Entry
  bind Entry <Command-Left> {
      %W icursor 0
      %W selection clear
  }
  bind Entry <Command-Right> {
      %W icursor end
      %W selection clear
  }
  bind Entry <Control-Left> {
      %W icursor 0
      %W selection clear
  }
  bind Entry <Control-Right> {
      %W icursor end
      %W selection clear
  }

  # TEntry
  bind TEntry <Command-Left> {
      %W icursor 0
      %W selection clear
  }
  bind TEntry <Command-Right> {
      %W icursor end
      %W selection clear
  }
  bind TEntry <Control-Left> {
      %W icursor 0
      %W selection clear
  }
  bind TEntry <Control-Right> {
      %W icursor end
      %W selection clear
  }
      }


tkt_uuid: 1919791fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: None
resolution: Accepted
title: XIM reorganization and cleanup
comment:
  Attached patch reorganizes and attempts to streamline Tk's XIM processing.

  It does not (to my knowledge) fix any of the outstanding XIM-related bugs in Tk, but I'd like to get it into Tk 8.5.2 anyway in the hopes of making those easier to debug in future.


tkt_uuid: 1920030fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 7 High
foundin: None
resolution: Fixed
title: Ttk stubs table
comment:
  Re: recent change to unix/Makefile.in:

  | Author: das <das>  2008-03-19 10:21:47
  | Committer: das <das>  2008-03-19 10:21:47
  |    ttkStubLib.o needs to be in tk library as well as stub library

  Why is this needed?  

  See also #1819422.  From talking with dgp, I think the consensus is that extensions should _either_ compile with -DUSE_FOO_STUBS and link with libfoostub.a, _or_ compile without -DUSE_FOO_STUBS and link directly against libfoo.a.

  There is no need, as far as I can tell, for TtkInitializeStubs or the rest of the stub mechanism to be included in libtk.so, and in fact this will break other linkage mechanisms (in particular any dependent extensions that link against Tile's stub library instead of Tk's).


tkt_uuid: 1921680fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 87. Logos
priority: 5 Medium
foundin: None
resolution: Fixed
title: Tk icon
comment:
  Code has been added to Tk8.5 that allows you to substitute the tk icon but for Tk < 8.5 and for people that don't have there own icon tk.ico should be updated to contain more resolutions and colour depths

  Bug #686329 provided tclkit.ico used in tclkit builds.

  Attached is tkicon.ico - its contains 16x16, 32x32, and 48x48 resolutions in both 24bit colour + 8bit alpha and 256 colours + 1bit alpha.

  The tk logo was vectorized and 3d shaded to produces these icons. No drop shadow was added. The SVG file is available to anyone that wants it.


tkt_uuid: 1922466fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 31. Cursor Names
priority: 9 Immediate
foundin: obsolete: 8.5.1
resolution: Accepted
title: Segfault setting a cursor with a four parameter list (X11)
comment:
  this small script makes wish segfault on X11

  . configure -cursor {@file.xbm file_mask.xbm black white}

  The problem resides in the file tkUnixCursor.c, line 496,  function CreateCursorFromTableOrFile. According to the comments at the begining and the inTkTable definition, if tkCursorPtr is non NULL then inTkTable is true, otherwise false. Thus the line 496

  if ((!inTkTable && (argc == 2)) || (tkCursorPtr->mask == NULL)) { 

  should be 

  if ((!inTkTable && (argc == 2)) || (inTkTable && tkCursorPtr->mask == NULL)) { 

  to prevent the dereference of tkCursorPtr if it's NULL.

  There is also a logic error in line 535

  if ((maskWidth != width) && (maskHeight != height)) {

  should be 

  if ((maskWidth != width) || (maskHeight != height)) {


  A small patch is attached


tkt_uuid: 1923684fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 8
foundin: None
resolution: Fixed
title: checkbox incompatible behaviour
comment:
  This thing:
  ---
    checkbutton $w.taskBar.dtwo -text "2-D" -onvalue "--dtwo" -offvalue "" -variable ${w}dtwo
  ---
  acts(drawn) as tristate checkbox, but such behaviour was not implied by the command.
  Such behaviour is not compatible with 8.14 tk.

  Andrey Gusev
  ag888@rambler.ru


tkt_uuid: 1924761fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 8
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Accented characters appearing at the end of the line
comment:
  Whenever a Tcl/Tk program that has a text widget in it freezes, all input characters that have been typed with a dead key appear at the end of the line upon unfreezing of the program, regardless of where they were actually typed. Furthermore, all the characters that appear are equal to the last accented character typed.
  For example (assuming the acute and grave accents require dead keys for input): typing "déjà-vu" while the program is frozen, would result in "dj-vuàà" appearing upon unfreezing.

  I have reported this bug again since it appears that the previous bug cannot be updated.


tkt_uuid: 1926223fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5.1
resolution: Fixed
title: A button doesn't flash on Windows.
comment:
  Cf. [ 1595773 ] button flash causes tcl to fail on Windows

  This all is still true on Windows XP.

  E. g.:

  button .b1 -text Hello -underline 0
      button .b2 -text World -underline 0
      bind . <Key-h> {.b1 flash; .b1 invoke}
      bind . <Key-w> {.b2 flash; .b2 invoke}
      pack .b1 .b2

  (the example from the documentation)

  doesn't work: no flashing.

  Werner


tkt_uuid: 1927212fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: None
resolution: None
title: scrollbar and MouseWheel
comment:
  The scrollbar should bind to MousWheel on non aqua platforms too:
  if {[tk windowingsystem] eq "aqua"} {
      bind Scrollbar <MouseWheel> {
          tk::ScrollByUnits %W v [expr {- (%D)}]
      }
      bind Scrollbar <Option-MouseWheel> {
          tk::ScrollByUnits %W v [expr {-10 * (%D)}]
      }
      bind Scrollbar <Shift-MouseWheel> {
          tk::ScrollByUnits %W h [expr {- (%D)}]
      }
      bind Scrollbar <Shift-Option-MouseWheel> {
          tk::ScrollByUnits %W h [expr {-10 * (%D)}]
      }
  }

  but the bindings look a bit different, see MouseWheel in library/text.tcl


tkt_uuid: 1934265fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Fixed
title: man2tcl does not honor quotes in macro arguments ->bind.n
comment:
  with the build target winhelp of makefile.vc, the help application man2tcl.c is build, which processes all files in the doc folder.

  An error in macro expansion in man2help2.tcl is invoked when processing bind.n.

  The problem:
  Quotes in macro arguemnt are not honored. Thus a space within quotes starts a new parameter.

  Input sequence:

  .ta \w'\fBButtonPress, Button\0\0\0\fR'u +\w'\fBKeyPress, Key\0\0\0\fR'u

  Current output:
  macro ta \\w'\\fBButtonPress, Button\ \ \ \\fR'u +\\w'\\fBKeyPress, Key\ \ \ 
  Desired output:
  macro ta \\w'\\fBButtonPress,\ Button\ \ \ \\fR'u +\\w'\\fBKeyPress,\ Key\ \ \ 

  A patch is attached (not including patch of Tcl Bug 1934200).
  To finally process the row correctly, man2help2.tcl also needs a patch, which is supplied in a following bug report.

  The files are in the Tcl 8.5.2 sources folder tools.
  The error arises when compiling Tk 8.5.2


tkt_uuid: 1934272fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 5 Medium
foundin: obsolete: 8.5.4
resolution: Fixed
title: man2help2.tcl: table macro \w false, invalid continue
comment:
  The script man2help2.tcl is invoked when the winhelp target is build using makefile.vc. Each file in doc is processed by man2tcl and then py this script.

  a) The table macro  (.ta) may contain width of string as table size using \w'Data'. The corresponding regular expression was corrected.

  Example from bind.n:
  .ta \w'\fBButtonPress, Button\0\0\0\fR'u +\w'\fBKeyPress, Key\0\0\0\fR'u
  man2tcl.exe output:
  macro ta \\w'\\fBButtonPress,\ Button\ \ \ \\fR'u +\\w'\\fBKeyPress,\ Key\ \ \ 
  This is now detected.

  b) An errornous "continue" in getTwips caused the script to fail

  c) Table size may have an R behind the unit (Why?).
  This is now honored with a warning

  The patch for tcl8.5.2/tools/man2help2.tcl is attached.

  Please look also to Bug Tcl 1934200 and Tk 1934265.


tkt_uuid: 1936220fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 8
foundin: obsolete: 8.6a2
resolution: Fixed
title: tk_getOpenFile -multiple 1 fails on Linux
comment:
  Using version 8.5.2, built from sources, with --enable-64-bit. OpenSuse version 10.3

  tk_getOpenFile -multiple 1 
  does not work. After selecting a few files (whose names correctly appear in File names listbox), pressing Open button results in failure message (which appears to arise from lines 1663/1664 of tkfbox.tcl.


  No problems with this on Windows, using ActibeState binary.

  Ian Gay
  gay@sfu.ca


tkt_uuid: 1936238fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 73. Argv Parsing
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Fixed
title: Tk_ParseArgv fails with wish8.5 -h
comment:
  This was originally reported on comp.lang.tcl by Simon Bachmann.

  To duplicate the problem run:
  $ wish8.5 -h
  or if you're using the HEAD:

  $ wish8.6 -h

  Tk_ParseArgv loops until it runs out of memory.

  kbk provided a patch that may fix the problem:
  http://paste.tclers.tk/857

  kbk said it needs a test case, and Tk_ParseArgv is currently not tested.


tkt_uuid: 1938580fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Fixed
title: 8.5 tkArgv.c PrintUsage -help crash
comment:
  Executing wish8.5 -help crashes from consuming all available memory.  The problem is in file generic/tkArgv.c in the function PrintUsage.  Going from 8.4 to 8.5, the variables width, i, numspaces and length have been changed to size_t which is unsigned.  The loop test while (numspaces > 0) is never false, so the interpreter is stuck allocating all memory for the interp result.

  To fix the problem, on line 340 of version 1.11 tkArgv.c, change size_t to int.  Then, to avoid compiler warnings, change "size_t length;" on line 354 to "int length;'


tkt_uuid: 1938774fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Duplicate
title: disable send -> X error on exit
comment:
  dgpHas something changed from Tk 8.4 -> Tk 8.5 when the [send] command is deleted?
  dgpI have a "big wish" program.
  dgpWhen I build it with Tcl/Tk 8.4.18, I can [rename send {}], and things work fine
  dgpWhen I build with core-8-5-branch, and enter [rename send {}; exit] at the interactive prompt, I get an X error....

  dgp$ ./omfsh
  X Error of failed request:  RenderBadPicture (invalid Picture parameter)
    Major opcode of failed request:  155 (RENDER)
    Minor opcode of failed request:  7 (RenderFreePicture)
    Picture id in failed request: 0x260003f
    Serial number of failed request:  1525
    Current serial number in output stream:  1582
  dgplook familiar to any Tk experts?


tkt_uuid: 1939129fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: Fixed
title: ::ttk::combobox posts badly with wm attr -topmost
comment:
  package require Ttk
  wm attribute . -topmost 1
  ::ttk::combobox .cb -values {a b c d}
  label .a -text "filler\nfiller\nfiller"
  pack .cb .a -side top


  Clicking the combobox causes the dropdown window to get drawn BEHIND the toplevel window because it has wm attribute -topmost 1.


tkt_uuid: 1941740fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 34. [tk_chooseColor]
priority: 5 Medium
foundin: None
resolution: Fixed
title: tk_chooseColor -title doesn't work on Win XP
comment:
  The -title option for tk_chooseColor doesn't seem to have any effect on Windows XP SP2 (using the native Windows dialog), it always comes up with the title "Color" regardless. Not sure if it's a bug, or just not possible to change on Windows and the documentation needs updating to reflect that..


tkt_uuid: 1942785fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: None
title: -default active on Aqua fails
comment:
  When I specifiy -default active for a button I expect it to be blue but it isn't. Moreover, the focus ring is not drawn either, see script:

  toplevel .t
  wm title .t "Press Tab"
  pack [ttk::frame .t.f -padding 40]
  set w .t.f
  ttk::button $w.b1 -text "Plain"
  ttk::button $w.b2 -text "-default normal" -default normal
  ttk::button $w.b3 -text "-default active" -default active
  ttk::button $w.b4 -text "-default disabled" -default disabled

  grid $w.b1 $w.b2 $w.b3 $w.b4 -padx 10


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

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

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


tkt_uuid: 1951055fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 8
foundin: obsolete: 8.5.3
resolution: Duplicate
title: nested [exit] hangs threaded Tk
comment:
  In a threaded wish, the following
  script hangs:

  bind . <Destroy> {+exit}
  exit

  The problem is that [exit]
  starts Tcl_Finalize().  Within
  that Tcl_FinalizeThread() triggers
  window <Destroy> bindings which
  calls a nested [exit] leading to
  nested Tcl_Finalize() calls.

  The nested Tcl_Finalize() call
  then gets stuck on TclpInitLock()
  and the process is hung.


tkt_uuid: 1954237fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: None
title: Doubleclick lost if processing click/release slow
comment:
  This problem occurs under Windows XP and MacOS 10.5 when using ActiveTcl 8.5.2. It also occurs on both those OS using various TclTk 8.4.x. It does not occur under Linux.

  Normally if you doubleclick, you get a <Button-1>, <ButtonRelease-1> and <Double-1> event in that order. However, if processing one of the first two takes more than a certain time, the Double event will not be generated at all. 

  This code snippet illustrates the problem; the loop count of 1e7 is right for my 2GHz core 2 duo MacBook. Interestingly if you divide this delay between the click and release events, the double is generated! But put it all on the release, and it is not. 
  ======
  proc delay {n} {
      for {set z 0} {$z < $n} {incr z} {}
  }

  pack [canvas .c]
  .c config -bg beige
  bind .c <Button-1> {delay 10000000; .c config -bg green}
  bind .c <ButtonRelease-1> {delay 0; .c config -bg yellow}
  bind .c <Double-1> {.c config -bg red; puts double}
  ======


tkt_uuid: 1954833fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: None
title: Busy canvas grinds after cursor change
comment:
  If you have a canvas with a large number of items (around 100000) and you change its cursor style, either for the canvas widget itself or some other widget above it in the hierarchy, then the cursor appearance changes immediately but the wish process is busy for about a second afterwards. I have checked this for Tk 8.4 and 8.5 under Linux, Windows and MacOS.

  This code snippet illustrates the problem -- click once and the cursor changes immediately, but click twice and the second change is delayed.
  ======
  pack [canvas .c -width 1000 -height 1000 -bg \#ffaaff]
  for {set y 0} {$y < 1000} {incr y 3} {
      for {set x 0} {$x < 1000} {incr x 3} {
          .c create line $x $y [expr $x+5] [expr $y+5]
      }
  }
  proc SwapCursor {} {
      if {[string equal watch [.c cget -cursor]]} {
          .c config -cursor arrow
      } else {
          .c config -cursor watch
      }
  }
  bind .c <Button-1> SwapCursor
  ======


tkt_uuid: 1954968fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: None
resolution: Invalid
title: [clipboard] takes selection ownership but has no lost event
comment:
  Using an example:

  % proc lostc {} {puts "Lost Clipboard"}
  % selection own -selection CLIPBOARD -command lostc .
  % clipboard append "."
  Lost Clipboard

  At this point the procedure lost is called.  But
  really the app still owns it, but now there's no
  way to trigger on the lost event.

  I'd like to propose a -command option to the clipboard
  command, which is identical to what selection -command does.   The first time clipboard takes ownership if
  the -command option is present, it is applied.

  Attached patch is a start.


tkt_uuid: 1955500fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: 8.4.19 fails windows compile and link with stock vc6.
comment:
  tkWinWm.c
  ..\win\tkWinWm.c(2993) : warning C4013: SetWindowLongPtr' undefined; assuming extern returning int

  ...

     Creating library .\Release\tk84.lib and object .\Release\tk84.exp
  tkWinWm.obj : error LNK2001: unresolved external symbol _SetWindowLongPtr
  .\Release\tk84.dll : fatal error LNK1120: 1 unresolved externals
  NMAKE : fatal error U1077: 'link' : return code '0x460'
  Stop.

  Though most places had been fixed, one was missed out
  in the recent set of fixes.  Diffs w.r.t 8.4.19 are:

  diff -u tkWinWm.c.orig tkWinWm.c 
  --- tkWinWm.c.origThu May  1 08:58:55 2008
  +++ tkWinWm.cThu May  1 08:59:44 2008
  @@ -2990,8 +2990,13 @@
        * translation.  Add the 0.5 to round the value.
        */
       if (!(wmPtr->exStyleConfig & WS_EX_LAYERED)) {
  +#ifdef _WIN64
   SetWindowLongPtr(wmPtr->wrapper, GWL_EXSTYLE,
   *stylePtr);
  +#else
  +SetWindowLong(wmPtr->wrapper, GWL_EXSTYLE,
  +*stylePtr);
  +#endif
       }
       setLayeredWindowAttributesProc((HWND) wmPtr->wrapper,
       wmPtr->colorref, (BYTE) (wmPtr->alpha * 255 + 0.5),


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

  TkpGetFontAttrsForChar: drawingContext not setup

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

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

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

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

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

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

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

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

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

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


tkt_uuid: 1957190fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Later
title: is "ttk::style element create" specification wrong?
comment:
  Hi,

  According to the docs, ttk::style element create is supposed to work like this:

    ttk::style element create elementName type ?args...?

  But then checking ttk.test at tk source package, I noticed it accepts this too:

    ttk::style element create plain.background from default

  And doing this:

    ttk::style element create plain.background from

  Returns me:

    wrong # args: should be "theme ?element?"

  Which confuses me even more, because I was expecting a return like: wrong # args: should be "ttk::style element  create name type ?options...?". 
  Does "plain.background from default" do something especial ? Does it return something that is then used by ttk::style element create ? Or is the specification incomplete ?

  Thanks


tkt_uuid: 1957792fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: None
title: Window not redrawn
comment:
  If I create a label widget with an image and this image is changed somehow, the widget does not get redrawn until I do something with it, like clicking at it etc. Reproduce this by having two images of the same size and do:

  set f1 [tk_getOpenFile]
  set f2 [tk_getOpenFile]
  set name1 [image create photo -file $f1]
  set name2 [image create photo -file $f2]
  pack [ttk::label .l -image $name1 -compound image -padding 100]

  # wait here and see the result then do

  $name1 copy $name2

  I'm runng 8.5.2 on an 10.5.2 Mac.
  Likely this happened when the extra double buffering was removed.


tkt_uuid: 1958367fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: None
title: Tk no longer builds correctly on Tru64
comment:
  I can build and run tk 8.4.19 with no problems on HP Tru64, but 8.5.2 doesn't work.  It looks like Tk adopted the TEA tcl.m4, but didn't incorporate the patch given in Tcl bug 1720242, <https://sourceforge.net/tracker/?func=detail&aid=1720242&group_id=10894&atid=310894>.

  You can easily duplicate this bug by using tclsh with "package require Tk" instead of invoking wish directly.


tkt_uuid: 1958848fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 78. Other Demos
priority: 5 Medium
foundin: None
resolution: Fixed
title: Intentionality failure in widget demo
comment:
  On the 'canvas item types' screen of this demo there is a button (embedded widget) that says 'Press Me'. But when you press it it says 'Ouch!!' Since it is asking to be pressed it should say 'Thank you'.


tkt_uuid: 1961455fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 9 Immediate
foundin: obsolete: 8.5.2
resolution: Fixed
title: Font underlining seems broken on X11
comment:
  The following should see the label's font underlined during mouse-over.

  ===========
  catch {font create url}
  catch {font create urlmo}
  font configure url   -family Arial -size 12 -underline 0
  font configure urlmo -family Arial -size 12 -underline 1

  grid [ttk::label .l -text "Should be underlined on mouse-over." -font url -foreground darkgreen]

  bind .l <Enter> ".l configure -cursor hand2 -font urlmo -foreground darkblue" 
  bind .l <Leave> ".l configure -cursor arrow -font url -foreground darkgreen" 
  bind .l <Button-1> ".l configure -font urlmo -foreground red ; # someProc"
  ===========

  The font's colour changes on X11 (so the rest of the configure works).

  Underline tested OK on Windows and Mac OS X.


tkt_uuid: 1962404fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 08. [(label)frame] and [toplevel]
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: None
title: "exit handlers were created during Tcl_Finalize" error
comment:
  DestroyNotify events on frames call TkSetWindowMenuBar to configure the menu for thr frame, which in turn registers for notice of program exit. Unfortunately if the window is being destroyed due to program exit then this causes the Tcl_Finalize function to abort() with a "exit handlers were created during Tcl_Finalize" message.

  The following example demonstrates it:

  wm protocol . WM_DELETE_WINDOW "exit"
  . configure -menu .m

  A workaround is to reset the frame menus before exiting. Eg:

  wm protocol . WM_DELETE_WINDOW "shutdown"
  . configure -menu .m

  proc shutdown {} {
      . configure -menu {}
      exit
  }

  This only happens when WM_DELETE_WINDOW is used on a window configured to have a menu, but I'm not entirely sure why.

  Commenting out the TkSetWindowMenuBar call cures the problem. Ie:

  *** tkFrame.c~  Sun Apr 29 03:24:02 2007
  --- tkFrame.c   Mon May 12 14:57:26 2008
  ***************
  *** 1627,1634 ****
          goto redraw;
        } else if (eventPtr->type == DestroyNotify) {
          if (framePtr->menuName != NULL) {
  -           TkSetWindowMenuBar(framePtr->interp, framePtr->tkwin,
  -                   framePtr->menuName, NULL);
              ckfree(framePtr->menuName);
              framePtr->menuName = NULL;
          }
  --- 1627,1632 ----

  I'm unsure of the impact of this change though. I cannot see why we'd ever want to reconfigure the menu bar of a window that is about to be destroyed, but that most likely means I'm missing something here.

  James


tkt_uuid: 1963903fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: None
title: Tk draws window at wrong screen coordinates
comment:
  On Windows XP, Tk seems to get confused about where on the screen to draw the toplevel window. To reproduce, perform these three commands one after another:

  package require Tk
  # <WAIT FOR TOPLEVEL TO APPEAR!>
  . configure -bg red
  . configure -bd 2 -rel sunk

  Sometimes the configuration changes will not seem to take effect until you move or refresh the toplevel, sometimes the changes will be drawn on a portion of the window.


tkt_uuid: 1965966fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: LAYOUTS doc missing some options
comment:
  Playing with ttk::style layout I noticed it accepts the options -side, -sticky, -children, -expand, -border and -unit. But only the first three are documented, any chance to get some description about the others ?

  Thanks.


tkt_uuid: 1967075fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: None
title: tk not allowed input nonlatin1 text
comment:
  Reproducer:
  1)
  LC_ALL=ru_RU.utf8 wish
  % encoding system
  utf-8
  % pack [text .t] -fill both

  2) try to type no latin text in text widget

  The window stay empty. This is not problem only with Cyrillic, but also other non latin-1 languages like Czech.

  Workaround: 
  create file ~/.i18n with your locales. Does it mean that wish isn't looking for locales into shell settings?


tkt_uuid: 1967576fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Fixed
title: Resizing a ttk::label panics as width or height equal zero
comment:
  WinXP SP3/ VC++ 2008 / Tcl/Tk 8.5.2

  Running this script:
    package require Img

    image create photo img::download -format PNG -file download.png
    
    ttk::label .w -image img::download
    pack .w -side left

  and then resizing the toplevel to zero height causes wish to panic with:

  "Unable to alloc 4294967040 bytes"


  The cause is the clipping operation in ttklabel.c ImageDraw.

  On resizing, the widget window dimensions become smaller than the element area dimensions. When this happens the image dimension are clipped to int -1. The width/height are then cast to a (unsigned int) very large positive integer in tkimgphoto.c ImgPhotoDisplay. Wish panics in tkwinimage.c XGetImageZPixmap when memory is being allocated for the image.

  Here's the stack:
  wish85sg!Tcl_PanicVA+0xe9
  wish85sg!Tcl_Panic+0x1e
  wish85sg!Tcl_Alloc+0x34
  wish85sg!XGetImageZPixmap+0x6e9
  wish85sg!XGetImage+0x193
  wish85sg!ImgPhotoDisplay+0xa7
  wish85sg!Tk_RedrawImage+0xd9
  wish85sg!ImageDraw+0x7e
  wish85sg!LabelElementDraw+0x134
  wish85sg!Ttk_DrawElement+0x7b
  wish85sg!Ttk_DrawNodeList+0xd4
  wish85sg!Ttk_DrawNodeList+0x7b
  wish85sg!Ttk_DrawNodeList+0x7b
  wish85sg!Ttk_DrawLayout+0x1b
  wish85sg!TtkWidgetDisplay+0x28
  wish85sg!DrawWidget+0x7b
  wish85sg!TclServiceIdle+0xa5
  wish85sg!Tcl_ServiceAll+0x117
  wish85sg!WmProc+0x639

  This patch fixes the problem, but maybe it would be better to fix the root cause above...

  Index: ttkLabel.c
  ===================================================================
  RCS file: /cvsroot/tktoolkit/tk/generic/ttk/ttkLabel.c,v
  retrieving revision 1.11
  diff -u -r1.11 ttkLabel.c
  --- ttkLabel.c13 Dec 2007 15:26:26 -00001.11
  +++ ttkLabel.c20 May 2008 00:25:12 -0000
  @@ -314,6 +314,13 @@
   height = Tk_Height(tkwin) - b.y;
       }
   
  +    if (width < 0) {
  +      width = 0;
  +    }
  +    if (height < 0) {
  +      height = 0;
  +    }
  +
       Tk_RedrawImage(image->tkimg, 0,0, width, height, d, b.x, b.y);
   
       /* If we're disabled there's no state-specific 'disabled' image, 


   


tkt_uuid: 1968592fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Works For Me
title: Double-clicking title bar doesn't minimize wish
comment:
  Double-clicking the titlebar should minimize apps on Mac OS X.

  In Tcl 8.5, double-clicking the Wish's titlebar does nothing.
  Note that this used to work a while back. For example in tcl 8.4.13.

  I don't know of any decent workaround.


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

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

  Other dialogs like tk_getOpenFile show the German labels fine.


tkt_uuid: 1982392fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Invalid
title: 8.5.2 compiles work, but wish fails
comment:
  I've done multiple 32-bit and 64-bit X11 compiles on our Mac hardware in the past without issue, but when I compile 8.5.2 the compile appears to work but wish crashes immediately when a button or label is created. I've tried it with and without the CoreFoundation stuff. I've tried with with the -O flag, and the -g flag. The 32-bit and 64-bit compiles fail with the same errors in the same location. It appears to have something to do with fonts, which might explain why button and label fail, but canvas and frame widgets don't. It fails remotely or at the system console.

  gdb reveals the following stack trace:

  % button .a -text a

  Program received signal EXC_BAD_ACCESS, Could not access memory.
  Reason: KERN_PROTECTION_FAILURE at address: 0x00000080
  0x0004420a in FcConfigAddCache ()
  (gdb) where
  #0  0x0004420a in FcConfigAddCache ()
  #1  0x000443b8 in FcConfigAddDirList ()
  #2  0x00044471 in FcConfigBuildFonts ()
  #3  0x0004fdc0 in FcInitLoadConfigAndFonts ()
  #4  0x0004fe0c in FcInit ()
  #5  0x0004450a in FcConfigGetCurrent ()
  #6  0x00046302 in FcConfigSubstituteWithPat ()
  #7  0x00046a07 in FcConfigSubstitute ()
  warning: .o file "/bir/dev/TCL-TK8.5.2/SRC/tk8.5.2/unix/MAC_I32/tkUnixRFont.o" more recent than executable timestamp
  #8  0x0b0f7cbf in InitFont (tkwin=0x381730, pattern=0x381f70, fontPtr=0x382320) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../unix/tkUnixRFont.c:214
  #9  0x0b0f827d in TkpGetFontFromAttributes (tkFontPtr=0x0, tkwin=0x381730, faPtr=0x35f808) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../unix/tkUnixRFont.c:390
  warning: .o file "/bir/dev/TCL-TK8.5.2/SRC/tk8.5.2/unix/MAC_I32/tkFont.o" more recent than executable timestamp
  #10 0x0b01d949 in Tk_AllocFontFromObj (interp=0x80a800, tkwin=0x381730, objPtr=0x835090) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../generic/tkFont.c:1169
  warning: .o file "/bir/dev/TCL-TK8.5.2/SRC/tk8.5.2/unix/MAC_I32/tkConfig.o" more recent than executable timestamp
  #11 0x0b015012 in DoObjConfig (interp=0x80a800, recordPtr=0x381b50 "0\0278", optionPtr=0x862b60, valuePtr=0x835090, tkwin=0x381730, savedOptionPtr=0x0) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../generic/tkConfig.c:773
  #12 0x0b014a25 in Tk_InitOptions (interp=0x80a800, recordPtr=0x381b50 "0\0278", optionTable=0x862a00, tkwin=0x381730) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../generic/tkConfig.c:553
  warning: .o file "/bir/dev/TCL-TK8.5.2/SRC/tk8.5.2/unix/MAC_I32/tkButton.o" more recent than executable timestamp
  #13 0x0b041f85 in ButtonCreate (clientData=0x0, interp=0x80a800, objc=6, objv=0xe5048, type=1) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../generic/tkButton.c:746
  #14 0x0b041a3a in Tk_ButtonObjCmd (clientData=0x0, interp=0x80a800, objc=6, objv=0xe5048) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../generic/tkButton.c:572
  #15 0x0a015179 in TclEvalObjvInternal (interp=0x80a800, objc=6, objv=0xe5048, command=0xffffffff <Address 0xffffffff out of bounds>, length=-1, flags=0) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclBasic.c:3649
  #16 0x0a06fc67 in TclExecuteByteCode (interp=0x80a800, codePtr=0x381690) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclExecute.c:2314
  #17 0x0a06d745 in TclCompEvalObj (interp=0x80a800, objPtr=0x81e100, invoker=0x0, word=0) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclExecute.c:1460
  #18 0x0a016b2d in TclEvalObjEx (interp=0x80a800, objPtr=0x81e100, flags=131072, invoker=0x0, word=0) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclBasic.c:4763
  #19 0x0a01660f in Tcl_EvalObjEx (interp=0x80a800, objPtr=0x80, flags=131072) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclBasic.c:4555
  #20 0x0a087611 in Tcl_RecordAndEvalObj (interp=0x80a800, cmdPtr=0x81e100, flags=131072) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclHistory.c:161
  #21 0x0a08739b in Tcl_RecordAndEval (interp=0x80a800, cmd=0x311330 "button .a -text a -font \"Fixed 10\"\n", flags=131072) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclHistory.c:59
  warning: .o file "/bir/dev/TCL-TK8.5.2/SRC/tk8.5.2/unix/MAC_I32/tkMain.o" more recent than executable timestamp
  #22 0x0b02d2d9 in StdinProc (clientData=0x329740, mask=2) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../generic/tkMain.c:390
  #23 0x0a09668b in Tcl_NotifyChannel (channel=0x329740, mask=2) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclIO.c:7781
  #24 0x0a0f587b in FileHandlerEventProc (evPtr=0x37e030, flags=-3) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../unix/tclUnixNotfy.c:635
  #25 0x0a0b5990 in Tcl_ServiceEvent (flags=-3) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclNotify.c:675
  #26 0x0a0b5d9f in Tcl_DoOneEvent (flags=-3) at /bir/dev/TCL-TK8.5.2/SRC/tcl8.5/unix/../generic/tclNotify.c:978
  warning: .o file "/bir/dev/TCL-TK8.5.2/SRC/tk8.5.2/unix/MAC_I32/tkEvent.o" more recent than executable timestamp
  #27 0x0b01afe0 in Tk_MainLoop () at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../generic/tkEvent.c:2114
  #28 0x0b02d082 in Tk_MainEx (argc=-1, argv=0xbffff7ec, appInitProc=0x5603 <Tcl_AppInit>, interp=0x80a800) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../generic/tkMain.c:321
  #29 0x000055fc in main (argc=1, argv=0xbffff7e8) at /bir/dev/TCL-TK8.5.2/SRC/tk8.5/unix/../unix/tkAppInit.c:68

  Any ideas or pointers as to what I should try next. I assume other are compiling X11 version of 8.5.2 on the Mac without error? I think I have modern hardware with the latest software (Leopard) and all updates installed.


tkt_uuid: 1986818fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: None
resolution: Accepted
title: tkUnixKey.c: Use Xutf8LookupString if available
comment:
  Attached patch modifies tkUnixKey.c to use Xutf8LookupString() instead of XmbLookupString() if the former is available.  This should solve problems (like #1908443) where Xlib's idea of the system encoding does not match Tcl's.

  Also fixes another bug whereby the results of XLookupString were being converted using the system encoding -- this is incorrect, XLookupString is documented to return ISO Latin 1 characters.

  (GPS, could you take a look?)


tkt_uuid: 1989808fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Accepted
title: extra ttk::notebook bindings
comment:
  It seems common, at least on Windows, to have PageUp and PageDown ky bindings for the notebook to cycle tabs. Firefox has it. Moreover, it binds not only to subwidgets of the notebook, but to any widget in the toplevel. Below is some code, mostly picked from library/ttk/notebook.tcl and modified.


  # Provides some extra bindings and workarounds for ttk::notebooks.
  # Code from ttk.

  namespace eval tileutils::nb {
      variable TLNotebooks
  }

  proc tileutils::nb::Traversal {nb} {
      variable TLNotebooks

      ttk::notebook::enableTraversal $nb

      set top [winfo toplevel $nb]
      if {![info exists TLNotebooks($top)]} {
  bind $top <Control-Next>  {+tileutils::nb::TLCycleTab %W  1}
  bind $top <Control-Prior> {+tileutils::nb::TLCycleTab %W -1}
  bind $top <Destroy>       {+tileutils::nb::TLCleanup %W}
      }
      bind $nb <Destroy> {+tileutils::nb::Cleanup %W}
      lappend TLNotebooks($top) $nb
  }

  # ActivateTab $nb $tab --
  #Select the specified tab and set focus.
  #
  # If $tab was already the current tab, set the focus to the
  #notebook widget.  Otherwise, set the focus to the first
  #traversable widget in the pane.  The behavior is that the
  #notebook takes focus when the user selects the same tab
  #a second time.  This mirrors Windows tab behavior.
  #
  proc tileutils::nb::ActivateTab {w tab} {
      if {[$w index $tab] eq [$w index current]} {
  focus $w
      } else {
      $w select $tab
  update ;# needed so focus logic sees correct mapped/unmapped states
  if {[set f [ttk::focusFirst [$w select]]] ne ""} {
      tk::TabToWindow $f
  }
      }
  }

  # CycleTab --
  #Select the next/previous tab in the list.
  #
  proc tileutils::nb::CycleTab {w dir} {
      if {[$w index end] != 0} {
  set current [$w index current]
  set select [expr {($current + $dir) % [$w index end]}]
  while {[$w tab $select -state] != "normal" && ($select != $current)} {
      set select [expr {($select + $dir) % [$w index end]}]
  }
  if {$select != $current} {
      ActivateTab $w $select
  }
      }
  }

  # tileutils::nb::ClosestNotebook --
  #       Finds notebook in toplevel that in some sense is closest to w.
  #
  proc tileutils::nb::ClosestNotebook {w} {    
      variable TLNotebooks
      
      set top [winfo toplevel $w]
      if {![info exists TLNotebooks($top)]} { return }
      if {[llength $TLNotebooks($top)] == 1} {
  return [lindex $TLNotebooks($top) 0] 
      }
      
      # Enclosing notebook.
      foreach nb $TLNotebooks($top) {
  if {[regexp ^$nb $w]} {
      return $nb
  }
      }
      
      # Find largest common part.
      set win $w
      while {($win ne $top) && ($win ne "")} {
  foreach nb $TLNotebooks($top) {
      if {[regexp ^$nb $win]} {
  return $nb
      }
  }
  set win [winfo parent $win]
      }
      return
  }

  # TLCycleTab --
  #toplevel binding procedure for Control-Tab / Shift-Control-Tab
  #Select the next/previous tab in the nearest ancestor notebook. 
  #
  proc tileutils::nb::TLCycleTab {w dir} {
      set nb [ClosestNotebook $w]
      if {$nb ne ""} {
  CycleTab $nb $dir
  return -code break
      }
  }

  # TLCleanup -- <Destroy> binding for traversal-enabled toplevels
  #
  proc tileutils::nb::TLCleanup {w} {
      variable TLNotebooks
      if {$w eq [winfo toplevel $w]} {
  unset -nocomplain -please TLNotebooks($w)
      }
  }

  # Cleanup -- <Destroy> binding for notebooks
  #
  proc tileutils::nb::Cleanup {nb} {
      variable TLNotebooks
      set top [winfo toplevel $nb]
      if {[info exists TLNotebooks($top)]} {
  set index [lsearch -exact $TLNotebooks($top) $nb]
          set TLNotebooks($top) [lreplace $TLNotebooks($top) $index $index]
      }
  }


tkt_uuid: 1991930fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Fixed
title: ttk combobox dropdown behind taskbar
comment:
  On windows XP SP2 using tcl/tk 8.5.2 from ActiveState.

  Part of the dropdown from a ttk combobox can be hidden behind the taskbar.

  The combobox is using the screen edge to determine whether to the display the dropdown above or below the entry box. It should either allow for the reduced dimensions due to the taskbar, or it should display in front of the taskbar even when taskbar is marked "on top".

  The following code will produce two combo boxes at the bottom edge of their window. When the window is maximised or moved near bottom of screen, the short list for the first combo box appears behind the taskbar whilst the longer list for the second combo box is correctly shown above it's entry box.


  package require Tk 8.5
  ttk::combobox .combo1 -state readonly -values {a}
  ttk::combobox .combo2 -state readonly -values {a b c d e f}
  grid .combo1 -column 0 -row 0 -sticky s
  grid .combo2 -column 1 -row 0 -sticky s
  grid columnconfigure . 0 -weight 1
  grid columnconfigure . 1 -weight 1
  grid rowconfigure . 0 -weight 1


  Checked what happens in a couple of other applications (Firefox and Internet Explorer), in both cases the dropdown from the address box appears in front of the taskbar. Suggest tk does the same.


tkt_uuid: 1994880fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Duplicate
title: tk_getOpenFile can't handle multiple files
comment:
  Using tk_getOpenFile with -multiple 1:

  I get an error popup saying 'File "/dir/file1 file2" 
  does not exist' when I try to open two files (file1 and file1) from the same directory (dir).

  Clearly the many elements in the multiple selection are not correctly handled but interpreted as a single file name.

  The problem seems to be that, after selecting multiple files in the icon list, clicking the OK button (Open) immediately **clears** the Icon selection. Because the multiple file counting relies on the selected icons, the program doesn't notice a multiple selection but considers that all the concatenated names is a single file name string...

  This didn't happen in 8.4. Do this test: select multiple files, and click-and-hold the "Open" button (do not release the mouse button). Notice the difference:

  In 8.4, clicking okBtn didn't clear the icon selection.

  In 8.5, clicking okBtn triggers ::tk::IconList_FocusOut too early. That clears the icon selection!


tkt_uuid: 1995663fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 8
foundin: obsolete: 8.5.2
resolution: Duplicate
title: Fatal Error in Wish
comment:
  The following code will produce a fatal error in Wish (Windows XP, Tcl/Tk 8.52, Tile 0.8.2), when the window is resized.  Details below the code...

  package require tile
  package require tkpng

  image create photo add -data {
      iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABGdBTUEAAK/INwWK6QAAAB
      l0RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAAJvSURBVDjLpZPrS5NhGIf9
      W7YvBYOkhlkoqCklWChv2WyKik7blnNris72bi6dus0DLZ0TDxW1odtopDs4D8MDZuLU0k
      Xq61CijSIIasOvv94VTUfLiB74fXngup7nvrnvJABJ/5PfLnTTdcwOj4RsdYmo5glBWP6i
      OtzwvIKSWstI0Wgx80SBblpKtE9KQs/We7EaWoT/8wbWP61gMmCH0lMDvokT4j25TiQU/I
      TFkek9Ow6+7WH2gwsmahCPdwyw75uw9HEO2gUZSkfyI9zBPCJOoJ2SMmg46N61YO/rNoa3
      9Xi41oFuXysMfh36/Fp0b7bAfWAH6RGi0HglWNCbzYgJaFjRv6zGuy+b9It96N3SQvNKiV
      9HvSaDfFEIxXItnPs23BzJQd6DDEVM0OKsoVwBG/1VMzpXVWhbkUM2K4oJBDYuGmbKIJ0q
      xsAbHfRLzbjcnUbFBIpx/qH3vQv9b3U03IQ/HfFkERTzfFj8w8jSpR7GBE123uFEYAzaDR
      IqX/2JAtJbDat/COkd7CNBva2cMvq0MGxp0PRSCPF8BXjWG3FgNHc9XPT71Ojy3sMFdfJR
      CeKxEsVtKwFHwALZfCUk3tIfNR8XiJwc1LmL4dg141JPKtj3WUdNFJqLGFVPC4OkR4Bxaj
      TWsChY64wmCnMxsWPCHcutKBxMVp5mxA1S+aMComToaqTRUQknLTH62kHOVEE+VQnjahsc
      NCy0cMBWsSI0TCQcZc5ALkEYckL5A5noWSBhfm2AecMAjbcRWV0pUTh0HE64TNf0mczcnn
      Qyu/MilaFJCae1nw2fbz1DnVOxyGTlKeZft/Ff8x1BRssfACjTwQAAAABJRU5ErkJggg==
  }


  foreach btn {.a .b .c .d .e .f .g .h} {
      ttk::button $btn -image add
      pack $btn -side left
  }

  The code will create a horizontal set of ttk buttons in a toplevel window.  Grab the right edge of the window and drag it narrower.  Once the right-most button's entire image is obscured, wish crashes with the following error dialog:

  ---------------------------
  Fatal Error in Wish
  ---------------------------
  unable to alloc 4294967232 bytes
  ---------------------------
  OK   
  ---------------------------

  Interestingly, changing the image to non-PNG-based data does not appear to cause the crash.  Also, it occurs whether using tkpng or img::png.

  Jeff


tkt_uuid: 1997293fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Mistake in manual page
comment:
  Description for tag option -relief has been corrected to being dependant on -borderwidth, but -borderwidth is still saying "is ignored unless the -background option has been set", which is incorrect.


tkt_uuid: 1997299fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.5.2
resolution: None
title: Tag borderwidth is leaking horizontally
comment:
  Observed behavior: when setting -relief non-flat and -borderwidth greater than tag width then relief border extends from left and right side over the area of tagged characters.

  Desired behavior: border being clipped horizontally the same way as it is clipped vertically, not extending the tagged area.

  Code example:

  font configure TkFixedFont -size 20
  pack [text .t -font TkFixedFont -height 5 -width 5]
  .t tag configure relief -relief solid -borderwidth 100
  .t insert 1.0 {
   ooo
   o} {} x relief {o
   ooo
  }


tkt_uuid: 1997907fffffffffffffffffffffffffffffffff
type: Support
status: Closed
subsystem: None
priority: 9 Immediate
foundin: None
title: tk::busy command
comment:
  Hi,

  After some discussions on #tcl, I started adding the BLT busy command to Tk as tk::busy. I've tried to convert as much as possible to the Tcl Object interface. Before writing a TIP I would like to get some feedback as this is my first try at writing a Tk core command.

  Attached the patch created with command

    % cvs -q diff -wuN > busypatch.txt

  based on the head revision.

  Also attached a summary of the commands.

  What's left to be done:

  - man page
  - tests for Tk test suite
  - Mac version?

  Jos.


tkt_uuid: 1999084fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Duplicate
title: focus bug during window activation (Aqua)
comment:
  Toplevel widows do not get focus when brought back from a minimized state
     
  To produce the bug:
  toplevel .t
  pack [text .t.t1]
  toplevel .t2

  1 click into .t2
  2 Minimize .t with the yellow button.
  3. when you deiconify the minimized window from the dock, the text box has no cursor, and also has no focus ring around it. It responds to button events but doesn't set a cursor.
  4. If you click into .t2, then back, the text box is activated again, has a cursor and a focus ring.

  if the console window is the next window down in the stack, so that it gets focus on minimizing, the bug doesn't happen.

  This bug was previously submitted, but marked obsolete without resolution. It still exists in the latest Aqua 8.5.2


tkt_uuid: 2000509fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 71. Error Handling
priority: 5 Medium
foundin: None
resolution: None
title: Segmentation fault
comment:
  Hello there,
  I am a new user of Python.
  I have installed Python packages TK & TCL (Version 8.5) and Python (Version 2.5) on Sun OS Version 5.8 Generic i386 machine.
  For installation I have used compiled source code from www.sunfreeware.com.
  I have also installed all dependent packages for Python.
  I am getting segmentation fault when I am trying to execute python gui which uses Tkinter widgets Button Label.

  Could you please advice me how to make Tkinter work on sun OS.

  Regards, Rinku


tkt_uuid: 2001072fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: Works For Me
title: tk_messageBox causes text entry to become unselectable
comment:
  Running this on windows:

  entry .e -textvariable foo
  pack .e
  set foo foo
  tk_messageBox -message hi 

  Cannot select the text in the entry. It WILL select if a console window is opened (so to reproduce, put code in a file and run via a command line - e.g. wish test.tcl - or tclkit test.tcl - if you open up a console and type in the commands it does NOT reproduce the error).

  I run on windows 2000, but others have reproduced this on xp and vista.


tkt_uuid: 2009213fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: Fixed
title: Segfault after setting bad -sliderrelief and packing scale
comment:
  Hi, I just noticed a segfault after setting the sliderrelief option of TScale's layout to some invalid value and then packing a ttk::scale. 

  Sample:

  ttk::style configure TScale -sliderrelief {}
  ttk::scale .s
  pack .s


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

      toplevel .d1
      #update
      wm forget .d1

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


tkt_uuid: 2010011fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: Ttk buttons keep focus when clicked
comment:
  When you click a regular Tk button, it won't take the focus from whichever widget currently has it (though you can still specifically give it focus via the keyboard).

  Ttk buttons (Win XP SP3, xpnative theme but with Windows configured to use the classic look) take focus when clicked, though. Brief example:

  pack [frame .top]
  pack [frame .btm]
  pack [button .top.btn -text "Tk" -command "puts Tk"]
  pack [ttk::button .top.btn2 -text "Ttk" -command "puts Ttk"]
  pack [text .btm.txt -width 10 -height 3]
  focus -force .btm.txt

  If you then click the Tk button, focus stays in the text widget. When you click the Ttk button, though, it retains focus.

  The issue is even worse when you combine several Tk/Ttk buttons; in the example above, click the 'Tk' button again. The Ttk button still retains focus afterwards, so even though it wasn't explicitly given focus via the keyboard (and although another button has been activated via the mouse), the Ttk button still remains active and can be invoked via the spacebar. 


tkt_uuid: 2010422fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: None
title: [bind] error - event parsing?
comment:
  After installation of Tk8.5.3 (with Tcl8.5.3)
  I get for several (all?) application the following
  error on startup
  fr
  Application initialization failed: Can't find a usable tk.tcl in the following directories: 
      /usr/local/beta/lib/tcl8.5/tk8.5 /usr/local/beta/lib/tk8.5 /usr/local/lib/tk8.5 /usr/local/beta/library

  /usr/local/beta/lib/tk8.5/tk.tcl: no event type or button # or keysym
  no event type or button # or keysym
      while executing
  "bind Listbox <MouseWheel> {
          %W yview scroll [expr {- (%D / 120) * 4}] units
      }"
      invoked from within
  "if {[tk windowingsystem] eq "aqua"} {
      bind Listbox <MouseWheel> {
          %W yview scroll [expr {- (%D)}] units
      }
      bind Listbox <Option-Mou..."
      (file "/usr/local/beta/lib/tk8.5/listbox.tcl" line 182)
      invoked from within
  "source /usr/local/beta/lib/tk8.5/listbox.tcl"
      (in namespace eval "::" script line 1)
      invoked from within
  "namespace eval :: [list source [file join $::tk_library $file.tcl]]"
      (procedure "SourceLibFile" line 2)
      invoked from within
  "SourceLibFile listbox"
      (in namespace eval "::tk" script line 4)
      invoked from within
  "namespace eval ::tk {
          SourceLibFile button
          SourceLibFile entry
          SourceLibFile listbox
          SourceLibFile menu
          SourceLibFile panedwindow
          SourceLibFile ..."
      invoked from within
  "if {$::tk_library ne ""} {
      proc ::tk::SourceLibFile {file} {
          namespace eval :: [list source [file join $::tk_library $file.tcl]]
      }
     ..."
      (file "/usr/local/beta/lib/tk8.5/tk.tcl" line 404)
      invoked from within
  "source /usr/local/beta/lib/tk8.5/tk.tcl"
      ("uplevel" body line 1)
      invoked from within
  "uplevel #0 [list source $file]"


  This probably means that tk wasn't installed properly.

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

  I've tried  gcc-4.3.1 and gcc-4.2.4 each with
  -O3 and -O .

  At the moment, Tcl8.5.3 (compiled with gcc-4.3.1 -O3)
  together with my previous  Tk8.5.2 (compiled with
  gcc-4.2.4 -O3) works just fine.

  I have a GenToo system, but install Tcl/Tk 8.5.x 
  separately with --prefix=/usr/local/beta

  More info about my gentoo system:
  emerge --info
  Portage 2.2_rc1 (default/linux/x86/2008.0, gcc-4.3.1, glibc-2.8_p20080602-r0, 2.6.25-gentoo-r4 i686)
  =================================================================
  System uname: Linux-2.6.25-gentoo-r4-i686-Intel-R-_Pentium-R-_III_CPU_family_1266MHz-with-glibc2.0
  Timestamp of tree: Thu, 03 Jul 2008 16:45:02 +0000
  ccache version 2.4 [disabled]
  app-shells/bash:     3.2_p39
  dev-java/java-config: 1.3.7, 2.1.6-r1
  dev-lang/python:     2.5.2-r5
  dev-python/pycrypto: 2.0.1-r6
  dev-util/ccache:     2.4-r7
  sys-apps/baselayout: 2.0.0
  sys-apps/openrc:     0.2.5
  sys-apps/sandbox:    1.2.20_alpha2-r1
  sys-devel/autoconf:  2.13, 2.62-r1
  sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1
  sys-devel/binutils:  2.18-r2
  sys-devel/gcc-config: 1.4.0-r4
  sys-devel/libtool:   2.2.4
  virtual/os-headers:  2.6.25-r4
  ACCEPT_KEYWORDS="x86 ~x86"
  CBUILD="i686-pc-linux-gnu"
  CFLAGS="-O2 -march=i686 -pipe"
  CHOST="i686-pc-linux-gnu"
  CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/lib/hsqldb"
  CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d"
  CXXFLAGS="-O2 -march=i686 -pipe"
  DISTDIR="/usr/portage/distfiles"
  FEATURES="buildpkg distlocks parallel-fetch preserve-libs sandbox sfperms strict unmerge-orphans userfetch"
  GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo "
  LDFLAGS=""
  LINGUAS="en de"
  MAKEOPTS="-j3"
  PKGDIR="/usr/portage/packages"
  PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
  PORTAGE_TMPDIR="/var/tmp"
  PORTDIR="/usr/portage"
  PORTDIR_OVERLAY="/usr/local/portage"
  SYNC="rsync://rsync.informatik.RWTH-Aachen.de/gentoo-portage"
  USE="X acl berkdb bitmap-fonts bzip2 cairo cdr cli cracklib crypt cups dbus doc dri dvd fortran gcj gdbm gnome gpm gtk gtk2 hal iconv ipv6 isdnlog jpeg kde midi mudflap ncurses nls nptl nptlonly opengl openmp pam pcre pdf perl png pppd python qt readline reflection session spl sqlite sqlite3 ssl svg tcl tcpd tetex tiff tk truetype-fonts type1-fonts unicode x86 xorg xulrunner zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en de" USERLAND="GNU" VIDEO_CARDS="nv"
  Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS


tkt_uuid: 2024595fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.6a1
resolution: Fixed
title: 2 button.test failures on WinXP
comment:
  Windows XP, compiled using MSVC:

  ==== button-5.5 ConfigureButton - image handling FAILED
  ==== Contents of test case:

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

  ---- Test cleanup failed:
  image "image1" doesn't exist
  ---- errorInfo(cleanup): image "image1" doesn't exist
      while executing
  "image delete image1 image2"
      ("uplevel" body line 3)
      invoked from within
  "uplevel 1 $cleanup"
  ---- errorCode(cleanup): NONE
  ==== button-5.5 FAILED



  ==== button-11.1 ButtonImageProc procedure FAILED
  ==== Contents of test case:

      .l configure -image image1 -padx 0 -pady 0 -bd 0
      pack .l
      set result "[winfo reqwidth .l] [winfo reqheight .l]"
      image1 changed 0 0 0 0 80 100
      lappend result [winfo reqwidth .l] [winfo reqheight .l]

  ---- Result was:
  34 19 84 104
  ---- Result should have been (exact matching):
  30 15 80 100
  ==== button-11.1 FAILED


tkt_uuid: 2024753fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.6a1
resolution: Fixed
title: listbox-28.2 duplication
comment:
  In listbox.test:

  test listbox-28.2 {listbox -activestyle} {!win} {
      destroy .l
      listbox .l
      .l cget -activestyle
  } dotbox
  test listbox-28.2 {listbox -activestyle} {win} {
      destroy .l
      listbox .l
      .l cget -activestyle
  } underline

  Each test name should be used only
  once.  A simple change to deal with
  this is to add .win to one of the test
  names.

  The !win constraint is using tcltest's
  constraint expressions "feature" which
  is really better off not used.  Create
  a named constraint with the meaning you
  need instead.

  I'll also suggest that the "win" constraint
  may not be the best to use.  The "win"
  constraint asserts the tests are running
  on some Windows system.  The graphical
  things getting tested here might be better
  served by a constraint directly connected
  to the [tk windowingsystem].

  Assigning to patthoyts since the bug
  originates with his commit, but feel
  free to pass on to aniap if you like.


tkt_uuid: 2026017fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.5.3
resolution: None
title: Event state bit mask is platform dependent
comment:
  When binding on motion events and looking the event %s state value to determine what modifier keys (shift, ctrl, alt, ...) are held down I get different results when Alt is held down on different platforms.  On Mac X11 Tk 8.5.2 the state value is 512 w/o any modifier keys and 512 + 8 with the standard macbook pro keyboard alt key held down.  On Mac Aqua Tk 8.5.2 I get 1024 with no modifiers and 1024 + 16 with Alt key pressed.  On Windows XP Home 32-bit I get 256 w/o any modifier and 256 + 131072 with left alt key pressed (Dell keyboard).

  On these platforms and also linux, the shift and ctrl modifiers use the same mask in the state field (1 for shift, 4 for ctrl).

  When the alt key is held during a motion event the same bit in the event state should be set on all platforms.

  Several messages on the web describe this problem and the contortions others have gone through to work around this problem:

  http://wiki.tcl.tk/4238

  http://www.faqts.com/knowledge_base/view.phtml/aid/4281


tkt_uuid: 2026405fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: winfo id bug in cygwin build
comment:
  Please excuse my poor English.
  TkpPrintWindowId() in tk/win/tkWinWindow.c uses sprintf() with format specifier "0x%p"

  msvc generates ordinary hex string like "8048354" for "%p", so "0x%p" generates string like "0x8048354".

  On the other hand, gcc (which is used by cygwin) adds "0x" prefix for "%p", so "0x%p" results in "0x0x8048354".
  This is not what you want.

  It would be nice if TkpPrintWindowId() checks _MSC_VER or something, and considers compiler-specific situations.


tkt_uuid: 2028703fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 9 Immediate
foundin: obsolete: 8.5.3
resolution: Fixed
title: Crash packing children into unmapped toplevel
comment:
  Bug 2009788 had Tk crashing when calling RemapWindows on an unmapped toplevel. Fixing that and adding further tests shows that packing a child widget into the unmapped/unmanaged toplevel will crash. This time its in TopLevelRequestProc called from Tk_GeometryRequest in the idle loop. The following test crashes on Windows with Tk HEAD and in 8.5.3.

  test wm-forget-1.4 "pack into unmapped toplevel causes crash" -body {
      toplevel .parent
      toplevel .parent.child
      wm forget .parent.child
      pack [button .parent.child.button -text Hello]
      after 250 {destroy .parent}
      tkwait window .parent
  } -cleanup {
      deleteWindows
  } -result {}


tkt_uuid: 2030200fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 3 Low
foundin: obsolete: 8.6a1
resolution: Fixed
title: Vista scrollbar arrows highlighting (tk and ttk)
comment:
  On Vista, the up and down arrows in a scrollbar widget should highlight when the mouse pointer enters the scrollbar, and unhighlight when the pointer leaves it.

  With current Tk scrollbars, the arrows sometimes highlight, but not correctly (i.e. on enter/leave). It seems they (un)highlight after clicking the scrollbar, and depending on whether the mouse button is released inside/outside of the scrollbar.

  With current Ttk scrollbars, the arrows never highlight.


tkt_uuid: 2031090fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: Duplicate
title: gitk crash with tk8.5.3
comment:
  Original bug report:
  Running gitk gives the attached output, gitk doesn't work right. Window opens, but can't do anything on it with the mouse

  I have the same output, but gitk isn't crashing. The message disappeared after removing last changes in tcl.tk file. I'll ask bug reporter, if my patch solved the gitk's crash.


tkt_uuid: 2031258fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.3
resolution: None
title: problem with Aqua Tk_Text in Tk>8.4
comment:
  I have come across a problem with Tk-text widgets for Tk>8.4, i.e  the new improved widgets. 
  Up to and including 8.4.x, text widgets took a long single logical line and handled it quite gracefully. 8.5 or 8.6 gets stuck really quickly. This code snippet will illustrate:
  <begin code>
     package require Tk

         font create dnafont  -family [font actual courier -family] -size 11
     text .t -yscrollcommand {.s set} -font dnafont -width 60 -wrap char  -setgrid true
     scrollbar .s -command {.t yview}
     pack .s -side right -fill y
     pack .t -side left -fill both -expand 1

         set insertion "ACGT"
         set data $insertion

         for { set i 1 } { $i <= 5000 } { incr i } {
         append data $insertion
         } # create a mock sequence of 20000 bases (long, but not terribly long)
     .t insert 0.0 $data
  <end code>
  Under 8.4 the window is reasonably responsive, under 8.5 it is a dead dog. This difference is not there under Windows.
  Tested using Tcl/Tk 8.5.3 and 8.6. Have used two different Macs, both PPC, running OS X 10.4.11.

  Looking at the platform-specific TkAqua code, it looks as if the whole thing is being passed off to system code in MeasureStringChars and ATSUBreakLine. I have been readin some of the old discussion on this area before posting and it seems as if there is a serious performance problem with ATSUBreakLine when faced with this kind of problem.
  I posted this on tcl-mac and was asked to post it as a bug here for the attention of 'benny' (Benjamin Riefenstahl).


tkt_uuid: 2034726fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: Works For Me
title: X11 Menus do not open
comment:
  Greetings,

  X11 menus do not open upon a mouse click, if the
  menubutton has no text but just an image and if
  the menu items are just images.
  Affected platforms are MacOSX/X11 _and_
  Debian 4.0/X11 with the Gnome desktop (focus follows
  mouse must be enabled on the latter!).

  The menu can still be opened, when the mouse is clicked
  on a neighboring menubutton and then moved (with the
  mouse button held down) over the menu that does not
  open in the first place.
  Disabling focus follows mouse in Gnome also helps.

  best regards,
  Randolf


tkt_uuid: 2039720fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 9 Immediate
foundin: obsolete: 8.6a1
resolution: Fixed
title: Tk doesn't need to manage XIDs
comment:
  After some discussion with Joe English, and subsequent discussions with the X.org developers, it has become apparent that Tk doesn't need to manage XIDs by replacing the core XID allocator.  This is all managed by the XC-MISC extension now that is very common.  I have also confirmed this by studying libX11 sources, which use XC-MISC.

  I have attached a patch to this bug report.  The patch makes Tk_FreeXId a no-op.  This patch also eliminates some unnecessary internal functions and function calls.

  keithp is Keith Packard of X.org in this discussion:

  <imaginator> Hi. I'm trying to get a definitive answer on whether or not XAllocID() can run out of ids these days. Does it make any attempt to reuse XIDs over a period of time?
  <keithp> imaginator: xlib manages reuse automatically
  <ajax> imaginator: if you have the XC-MISC extension on your server (and you do) then they get reused internally, yes.
  <ajax> you can still run out, but that requires actually consuming all of the XID space
  <imaginator> ok, so an application that runs a long time will no longer need to reuse XIDs or replace the core dpy->resource_alloc?
  <keithp> imaginator: right
  <imaginator> ok, good to know. So it seems we can put this code to rest in Tk: http://tktoolkit.cvs.sourceforge.net/tktoolkit/tk/unix/tkUnixXId.c?revision=1.11&view=markup
  <ajax> oh my.
  <imaginator> ajax?
  <ajax> yes, please do
  <keithp> imaginator: uh, yeah, since like 1993
  <ajax> i just didn't know tk did that
  <imaginator> How does the XC-MISC extension do this, and how common is the XC-MISC extension?
  <ajax> it asks the server for a list of unused IDs
  <keithp> imaginator: it's been around in every X server for 15 years
  <imaginator> thank you :)
  <imaginator> Now I think I have suitable justification to nuke this code.
    


tkt_uuid: 2049429fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.3
resolution: None
title: Some options aren't picked up from the options database
comment:
  The text widget ignore the value in the option database for certain options. Examples are -spacing[123]. This fact is not documented in the text manual page.

  After a bit of source diving, there's an option in the 'flags' field of the Tk_OptionSpec struct in tkText.c named TK_OPTION_DONT_SET_DEFAULT which prevents the value to be read form the option database (line 490 of tkConfig.c). This value is not documented in the Tk_SetOptions manual page, which states " At present only a single flag is supported: TK_OPTION_NULL_OK". There is also TK_CONFIG_NULL_OK in tkText.c, also not documented.


tkt_uuid: 2053879fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: Fixed
title: image in a tag isn't used for items in ttk::treeview
comment:
  Shouldn't the inserted item in the following code have an image ?

  """
  package require Tk

  image create photo test1 -file test1.gif
  ttk::treeview .t
  .t tag configure imgtest -image test1
  .t insert {} end -text test -tags imgtest
  pack .t
  """

  The "imgtest" tag should provide the "test1" image to that item, since that item has no image directly associated with it.


tkt_uuid: 2053891fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.5.4
resolution: Invalid
title: Build fails in tkMacOSXColor.c
comment:
  Downloaded tcl&tk 8.5.4-rc2 tonight. Tcl built fine, but when I tried to build Tk (cd to tk8.5.4/macosx directory; make) I got an error:

  make tk \
  BUILD_STYLE=Development CONFIGURE_ARGS=--enable-symbols   
  make install-tk INSTALL_ROOT="/Installerare/Tcl/tk8.5.4/macosx/../../build/tk/Development/"
  make -C "/Installerare/Tcl/tk8.5.4/macosx/../../build/tk/Development" all tktest INSTALL_ROOT='/Installerare/Tcl/tk8.5.4/macosx/../../build/tk/Development/' INSTALL_TARGETS='install-binaries install-libraries install-private-headers install-demos' VERSION='8.5'  
  gcc -c -g -pipe  -fpascal-strings   -Wall -Wno-implicit-int -fno-common -I/Installerare/Tcl/tk8.5.4/unix/../unix -I/Installerare/Tcl/tk8.5.4/unix/../generic -I/Installerare/Tcl/tk8.5.4/unix/../bitmaps -I/Installerare/Tcl/tcl8.5.4/generic -I/Installerare/Tcl/tcl8.5.4/unix -I/Installerare/Tcl/tk8.5.4/unix/../macosx -I/Installerare/Tcl/tk8.5.4/unix/../xlib -DPACKAGE_NAME=\"tk\" -DPACKAGE_TARNAME=\"tk\" -DPACKAGE_VERSION=\"8.5\" -DPACKAGE_STRING=\"tk\ 8.5\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DHAVE_PTHREAD_GET_STACKSIZE_NP=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\ __attribute__\(\(__visibility__\(\"hidden\"\)\)\) -DMAC_OSX_TCL=1 -DHAVE_COREFOUNDATION=1 -DTCL_SHLIB_EXT=\".dylib\" -DTCL_CFG_DEBUG=1 -DTCL_WIDE_INT_TYPE=long\ long -DWORDS_BIGENDIAN=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DHAVE_PW_GECOS=1 -DMAC_OSX_TK=1 -DTK_MAC_DEBUG=1 -DTK_FRAMEWORK=1      -DTCL_NO_DEPRECATED -DTK_FRAMEWORK_VERSION=\"8.5\" -DUSE_TCL_STUBS  /Installerare/Tcl/tk8.5.4/unix/../macosx/tkMacOSXColor.c
  /Installerare/Tcl/tk8.5.4/unix/../macosx/tkMacOSXColor.c: In function 'TkMacOSXSetColorInContext':
  /Installerare/Tcl/tk8.5.4/unix/../macosx/tkMacOSXColor.c:473: error: 'kCGBitmapByteOrder32Host' undeclared (first use in this function)
  /Installerare/Tcl/tk8.5.4/unix/../macosx/tkMacOSXColor.c:473: error: (Each undeclared identifier is reported only once
  /Installerare/Tcl/tk8.5.4/unix/../macosx/tkMacOSXColor.c:473: error: for each function it appears in.)
  make[3]: *** [tkMacOSXColor.o] Error 1
  make[2]: *** [build-tk] Error 2
  make[1]: *** [tk] Error 2
  make: *** [develop] Error 2

  [hexley:Tcl/tk8.5.4/macosx] lars% uname -a
  Darwin hexley.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc

  I'm not sure I've ever succeeded in building Tk myself (TclTkAqua has always been so convenient, and TclTkAquaBI even more so), so this might just be me, but the above looks more like the error is that some case (big-endian & something?) has been forgotten somewhere. Anyway, I'm in no hurry (my installed 8.5.0 is fine for the moment), but it's a pity I didn't try this a few days ago. :-(


tkt_uuid: 2054562fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: native sashcursors on MacOS X
comment:
  ttk doesn't use the native sashcursors on MacOS X (with Tk 8.5.3). Furthermore, "southeast" resizing uses the arrow cursor there. The fix is simply to adjust the Cursors array in ttk/cursors.tcl:

  <snip>
  "unix" -
  * {
  if {$::tcl_platform(os) == "Darwin"} {
  array set Cursors {
  hresize resizeleftright
  vresize resizeupdown
  seresizearrow
      }
  } else {
      array set Cursors {
  hresize sb_h_double_arrow
  vresize sb_v_double_arrow
  seresizebottom_right_corner
      }
      }
  }
  </snip>


  Cheers,
  Reinhold Straub
  demarchie@web.de


tkt_uuid: 2058868fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: None
resolution: None
title: Spinbox Options
comment:
  The current behaviour of a spinbox differs from that of other widgets such as radiobuttions, checkbuttons and labels in that the initial value is the first item in a values list unlike radio/check buttons & labels which adopt any stored value of -variable or -textvariable as the initial value

  This limits the functionality and is confusing (at least to me)

  To preserve current functionality but extend the capability I would propose an additional option of
  -initialvalue

  The behaviour should be to confirm this is a valid item in the -values list and if it is than this value should be displayed in the widget, if it is not a valid item then the first item in the values list should be
  displayed

  Spinbox is different to the other widgets in that there are multiple potential -values hence the need for an additional option to nominate the initial value where it is relevant. 

  A good string value example is selection of a username from a preset list of usernames & storage of the selection between sessions. 

  A good numeric example would be a scale of -10 to +10 with an initial value of 0

  please refer to ActiveTcl Bug 71910: and 

  http://sourceforge.net/tracker/index.php?func=detail&aid=1778168&group_id=12997&atid=362997

  for other comments



  bugs@crossroadz.com.au


tkt_uuid: 2062394fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.5.4
resolution: Invalid
title: Incompatible change in grid command
comment:
  Tk8.5 introduces a new subcommand to grid called 
  "anchor". This subcommand controls the placing of
  grids which are smaller than its containing widget.
  Unfortunately the default behaviour is set to
  "nw" while in Tk8.4 (where you couldn't specify
  the anchor) it was "center".

  This leads to some broken layouts, like 
  iwidgets disjointlistbox with "-buttonplacement center".

  A short Tk-only example for demonstration:

  <tcl>
  frame .f -background blue
  button .f.b1 -text "Button 1"
  button .f.b2 -text "Button 2"

  # uncomment next line for 8.5 compatiblity
  #grid anchor .f center
  grid .f.b1
  grid .f.b2

  pack .f -fill both -expand true
  wm geometry . =200x800
  </tcl>

  Running this, you will see the buttons are in the
  center using 8.4 and in the upper left corner 
  using 8.5. For the latter the "grid anchor" line 
  is necessary to yield the same result (but isn't
  backward compatible).


tkt_uuid: 2064914fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.4
resolution: None
title: Ttk::menubutton -width overrides its real width
comment:
  Consider the following example:

  pack [text .t]
  pack [ttk::menubutton .mb -text somestring -width 1] -fill x

  The menubutton is created with "-width 1", but afterwards it becomes bigger because it is packed with -fill x.
  The result is that the menubutton's width is indeed increased, but instead of "somestring" it only displays "so".

  A ttk::button will display the full string in the same situation, as will a non-ttk menubutton. I think a ttk::menubutton should behave like these.


tkt_uuid: 2073526fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4.7
resolution: None
title: Accented characters in text widget, linux
comment:
  I've observed this problem using an old version of Tk (8.4.7). Maybe it's solved in newer versions, but I couldn't check. I happens in Linux, but not in Windows.

  The problem happens when I try to type an accented character like á (this is &aacute; in HTML, in case that you cannot see correctly). To try this with an English keyboard, there should be an accent character if you press AltGr+#, for instance.

  The problem is the following one. If I do:

  > text .t
  > pack .t

  The accented characters work, and I can type á by pressing first the ´ character, releasing the key, and then typing the a.

  But if I pack any other widget afterwards, for instance:

  > frame .f
  > pack .f

  Then the accented characters stop working and I can only type a.

  Finally, if I create another text widget:

  > text .u
  > pack .u

  I can only type á in the second text, but the first one still doesn't work.

  I've traced the binding for <Key> in the Text class. When I pack only the first text, .t, the binding executes only after I've hit the two keys:

  tk::TextInsert .t á

  And after I've packed the frame .f, it executes immediately after I hit each key:

  tk::TextInsert .t {}        <-- when I hit ´
  tk::TextInsert .t a         <-- when I hit a


tkt_uuid: 2073724fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 3 Low
foundin: None
resolution: Duplicate
title: Bad text selection anchor mark name
comment:
  In the bindings of the text widget, tk::anchor$w is used as the name of a mark (for anchoring the selection), where $w is the name of the widget.

  This is not a good idea since $w may be illegal for use in a mark name. For example, a text widget can be named ".t-1c", which causes serious problems when used in a mark name... (The "-1c" is confused with an index computation).

  (Low priority bug, since it only occurs with exotic widget names.)


tkt_uuid: 2075285fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.5.4
resolution: Wont Fix
title: grid column not visible
comment:
  In the script below, the column containing canvas .c is not visible. OTOH if the entry .e is created with '-width 4' evrything looks fine. 

  I'm using ActiveTcl 8.5.4 on Windows XP, but I also see this with Tclkit 8.5a4 on Linux.

  #entry .e -width 4
  entry .e -width 40
  grid .e -columnspan 9 -sticky e
  text .t1 -width 10 -height 20
  grid .t1 -row 1 -column 0 -columnspan 3 -sticky ewns
  grid columnconfigure . 1 -weight 1
  canvas .c -width 9 -height 1 -relief raised -bg black 
  grid .c -row 1 -column 3 -columnspan 3 -sticky ns
  text .t2 -width 10 -height 20
  grid .t2 -row 1 -column 6 -columnspan 3 -sticky ewns
  grid columnconfigure . 7 -weight 1
  wm deiconify .


tkt_uuid: 2080533fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 9 Immediate
foundin: obsolete: 8.4.13
resolution: Fixed
title: panedwindow widget crash issue
comment:
  Hi,

  We are having a crash on some Windows XP 32bit machines (using an nVidia graphics card). It looks like it is happening in the panedwindow widget when it is drawing the sash. The crash seems to be related to a large screen resolution (1920X1200).
  Is anyone aware of this issue, and/or have a fix for this?

  We are using Tk version 8.4.13.

  Your replies are appreciated.

  Thanks,
  Mona.


tkt_uuid: 2080587fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: Fixed
title: failing imgPhoto tests
comment:
  ==== imgPhoto-4.67 ImgPhotoCmd procedure: transparency set option FAILED
  ==== Contents of test case:

      photo1 put white -to 0 0 3 3
      checkImgTransLoopSetReset photo1 3 3

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: image "img" doesn't exist
      while executing
  "image width $img"
      (procedure "foreachPixel" line 3)
      invoked from within
  "foreachPixel img x y {
              $img put white -to 0 0 3 3
              $img transparency set $x $y 1
              lappend result {*}[checkImgTrans $img]
              append resu..."
      (procedure "checkImgTransLoopSetReset" line 3)
      invoked from within
  "checkImgTransLoopSetReset photo1 3 3"
      ("uplevel" body line 3)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== imgPhoto-4.67 FAILED



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

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

  ---- Result was:
  0,2 2,0
  ---- Result should have been (exact matching):
  0 2 2 0
  ==== imgPhoto-4.71 FAILED



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

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

  ---- Result was:
  0,2 2,0
  ---- Result should have been (exact matching):
  0 2 2 0
  ==== imgPhoto-4.72 FAILED



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

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

  ---- Result was:
  0,2 1,1 2,0
  ---- Result should have been (exact matching):
  0 2 1 1 2 0
  ==== imgPhoto-4.73 FAILED


tkt_uuid: 2088597fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 16. [scrollbar]
priority: 9 Immediate
foundin: None
resolution: Accepted
title: minimum scrollbar slider length (Unix)
comment:
  The scrollbar slider has a minimum length, denoted by "MIN_SLIDER_LENGTH" in the scrollbar code.

  However, this miminum length is not honoured when the slider is right at the bottom, which makes it difficult to pick up with the mouse to drag it.

  I've attached a patch to fix this issue.


tkt_uuid: 2093072fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.5.4
resolution: Works For Me
title: makefile.vc requires macro _INSTALLDIR
comment:
  Environment:
  - Windows Vista Pro German
  - MS-VC++6
  - Windows Server 2003 SP1 SDK (Release)

  C:\test\tk8.5.4\win>nmake -f makefile.vc install TCLDIR=c:\test\tcl8.5.4 INSTALLDIR=c:\test\tcl854 _INSTALLDIR=c:\test\tcl854

  Installs into c:\test\tcl854\..

  I have no idea where the additional path component ".." comes from.
  Anyway, after the install, the folders c:\test\lib etc. exists with the tk contents. The makefile fails while integrating the tcl helpfile into the tk one. The tcl helpfile is not found in the installation destination path.

  A workaround is to specify also the variable "_INSTALLDIR", which is used in the makefile:

  C:\test\tk8.5.4\win>nmake -f makefile.vc install TCLDIR=c:\test\tcl8.5.4 INSTALLDIR=c:\test\tcl854 _INSTALLDIR=c:\test\tcl854

  Notes:
  - This bug was not present in tcl8.5.3.
  - To build the winhelp, the patches of the following bugs must be applied:
    - TCL:1934200
    - TK: 1934272


tkt_uuid: 2095675fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 8
foundin: obsolete: 8.6a2
resolution: None
title: fedora 9 tk.spec failure and fix
comment:
  # rpmbuild -ta /usr/src/redhat/SOURCES/tk8.6a2-src.tar.gz 
  error: Failed build dependencies:
  XFree86-devel is needed by tk-8.6a2-2.i386

  The above error is discussed at the following document.
  https://www.redhat.com/archives/fedora-devel-list/2005-November/msg00277.html

  A way to deal with it is discussed at the following document.
  http://fedoraproject.org/wiki/DistTag

  Attached is a patch to fix the spec, and the fixed spec that worked for me on Fedora 9.


tkt_uuid: 2098425fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: Fixed
title: typo in menu.n
comment:
  In menu.n, the "Pulldown Menus in Menubar" section starts with the sentence:

  This is the most command case.

  It should be:

  This is the most common case.


tkt_uuid: 2099926fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: None
priority: 5 Medium
foundin: None
resolution: None
title: Failed build with OPTS=static,staticpkg
comment:
  Hi,

  This patch is related to Tcl patch 1998813.

  When building Tk with OPTS=static,staticpkg errors are reported about missing dde libs. These are caused by these lines in the makefile.vc:

  WISHOBJS = \
  $(TMP_DIR)\winMain.obj \
  !if $(TCL_USE_STATIC_PACKAGES)
  $(TCLDDELIB) \
  $(TCLREGLIB) \
  !endif
  $(TMP_DIR)\wish.res

  Replacing these with:

  WISHOBJS = \
  $(TMP_DIR)\winMain.obj \
  !if $(TCL_USE_STATIC_PACKAGES)
  "$(_TCLDIR)\win\$(BUILDDIRTOP)\tcl_Static\tclWinReg.obj" \
  "$(_TCLDIR)\win\$(BUILDDIRTOP)\tcl_Static\tclWinDde.obj" \
  !endif
  $(TMP_DIR)\wish.res

  solves the problem.

  Kind regards,

  Jos.


tkt_uuid: 2100430fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
severity: Minor
foundin: current: 8.5.14
resolution: Fixed
title: ttk::entry widget index must be integer
comment:
  Attempting to adjust the xview of a ttk::entry widget to show the insertion cursor with: 

     pathname xview insert

  results in an error message stating an integer is required.  Similar error with end index.  Easy local fixes with:

      pathname xview [pathname index insert]
  and
     pathname xview [pathname index end]

  but not as documented or as per original entry widget.


tkt_uuid: 2100553fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 82. X11 Emulation
priority: 5 Medium
foundin: obsolete: 8.5.2
resolution: None
title: Panic in ImgPhotoGet
comment:
  Windows users of an application I have written report that the application sometimes crashes with the following message: 
     Fatal Error in Wish
     ImgPhotoGet couldn't find visual for window

  A common factor appears to be that the users experiencing the problem all use windows remote desktop connection form one or more machines to connect to the machine running the application.

  Sources on the internet point the finger to changes in color depth as the cause of the error. Also according to Donal Fellows on c.l.t: "Tk-on-Win assumes — wrongly — that the display depth doesn't change (...) Once that assumption is fixed, the photo image code will just work as that already knows in itself how to handle different visuals/colormaps."

  The problem was seen on Windows XP with Tk 8.5.2.


tkt_uuid: 2107938fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 5 Medium
foundin: obsolete: 8.6a4
resolution: Fixed
title: Mirrored text if Xft is used
comment:
  Hi!

  Appears that if Xft-enabled fonts are used and font size is negative (gives size in pixels, not in points) then canvas postscript prints text inverted (rotated at 180 degrees).

  The problem is that Tk_PostscriptFontName() is expected to return font size in points, but it returns just TkFont size attribute which may be negative.

  The attached patch converts negative size attribute to positive, so canvas postscript becomes working again.


tkt_uuid: 2108391fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: None
title: entry -validate set to none incorrectly
comment:
  #
  # This bug MAY be related to bug 1520118.
  #
  # This should be the minimal test script to repro 
  # the problem:
  #
  set foo ""

  pack [entry .foo -validate key -validatecommand [list regexp -- {^[A-Z]*$} %P] -textvariable ::foo]

  bind . <F1> [list doStuff]
  bind . <F2> [list .foo configure -show ""]

  proc doStuff {} {
    set ::foo "ABCD        "; # <-- has invalid chars
    .foo configure -show *
  }


tkt_uuid: 2108411fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: Invalid
title: checkbutton menu entry odd behavior
comment:
  # This should be the minimal repro script: 

  pack [entry .entry]; update

  menu .menuBar
  . configure -menu .menuBar

  menu .menuBar.testMenu -tearoff 0

  tk_messageBox -message \
      "ismapped = [winfo ismapped .entry]"

  .menuBar.testMenu add checkbutton -label \
      "Menu Label Here" -underline 0 \
      -indicatoron [winfo ismapped .entry] \
      -command [list doStuff]

  set index [.menuBar.testMenu index "Menu Label Here"]

  #
  # BUG 1: The -variable option has not been set,
  #        yet it has the same value as the -label 
  #        option?
  #
  tk_messageBox -message \
      "-variable = [.menuBar.testMenu entryconfigure $index -variable]"

  .menuBar add cascade -menu .menuBar.testMenu \
      -label "Menu" -underline 0

  bind . <F2> [list console show]
  bind . <F7> [list doStuff]

  wm geometry . 200x200

  proc doStuff {} {
    if {[winfo ismapped .entry]} then {
      pack forget .entry; update
    } else {
      pack .entry; update
    }

    tk_messageBox -message \
        "ismapped = [winfo ismapped .entry]"

    #
    # BUG 2: This does not seem to have any effect 
    #        on the user interface.
    #
    .menuBar.testMenu entryconfigure $::index \
        -indicatoron [winfo ismapped .entry]
  }


tkt_uuid: 2110385fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 9 Immediate
foundin: obsolete: 8.5.4
resolution: Duplicate
title: tk:messageBox OSX -title -icon defunct
comment:
  on Max OS X 10.5.4 i found the -title and -icon options defunct.

  in wish try this:
  tk_messageBox -title title -icon error -message message -detail detail

  will result in 
  - no title
  - standard icon



  kind regards,
  uwe


tkt_uuid: 2112042fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: Invalid
title: menu.tcl: error with two arguments called
comment:
  wrong # args: should be "error error"
  wrong # args: should be "error error"
      while executing
  "error $msg $savedInfo"
      (procedure "tk::MbPost" line 115)
      invoked from within
  "tk::MbPost $tk::Priv(inMenubutton) 229 488"
      invoked from within
  "if {$tk::Priv(inMenubutton) ne ""} {
  tk::MbPost $tk::Priv(inMenubutton) 229 488
      }"
      (command bound to event)

  Solution: add quotes...


tkt_uuid: 2112563fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 7 High
foundin: obsolete: 8.5.4
resolution: Remind
title: Tk is not safe against extensions that call setlocale().
comment:
  Hi,
  Tcl/Tk 8.5 had a huge refactoring in order to become locale-independent.
  The problem is that I'm using an extension which calls :
    setlocale(LC_ALL, "")
  on a french desktop, and this causes Tk to report an error.
  There are still some 'sprintf' calls in tk's source which are causing this issue.
  The code to reproduce the error, as well as it's output is here : http://pastebin.com/m14756d67
  You can replace the 'package require farsight' by a 'load' to any extension doing a :
    setlocale(LC_ALL, "fr_FR.UTF-8@euro");

  I did a grep on tk's 8.5.4 source and here's the list of sprintf's being used : 

  kakaroto% grep -r printf * | grep "%g"
  generic/ttk/ttkScroll.c:    sprintf(args, " %g %g",
  generic/ttk/ttkScroll.c:        sprintf(buf, "%g %g",
  generic/tkScrollbar.c:  sprintf(buf, "%g", fraction);
  generic/tkScrollbar.c:  sprintf(buf, "%g", fraction);
  generic/tkArgv.c:               sprintf(tmp, "%g", *((double *) infoPtr->dst));
  generic/tkEntry.c:          sprintf(buf, "%g %g", first, last);
  generic/tkEntry.c:    sprintf(args, " %g %g", first, last);
  generic/tkEntry.c:          sprintf(buf, "%g %g", first, last);
  generic/tkCanvText.c:    sprintf(buffer, "] %d %g %g %s %s DrawText\n",
  generic/tkListbox.c:        sprintf(buf, "%g %g", fraction, fraction2);
  generic/tkListbox.c:        sprintf(buf, "%g %g", fraction, fraction2);
  generic/tkListbox.c:    sprintf(string, " %g %g", first, last);
  generic/tkListbox.c:    sprintf(string, " %g %g", first, last);
  macosx/tkMacOSXScrlbr.c:            sprintf(valueString, "%g", newFirstFraction);
  macosx/tkMacOSXScrlbr.c:        sprintf(valueString, "%g",
  macosx/tkMacOSXScrlbr.c:                sprintf(valueString, "%g",
  win/tkWinScrlbr.c:          sprintf(valueString, "%g", pos);

  Thanks,
  KaKaRoTo


tkt_uuid: 2116837fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 9 Immediate
foundin: obsolete: 8.4.14
resolution: Fixed
title: EZ Fix for <<Copy>> <<Paste>> <<Cut>> to work w/CAP-LOCK
comment:
  Under Tcl/Tk 8.4.14 and earlier the default sequences for the <<Copy>> <<Paste>> and <<Cut>> virtual events do not operate with the CAPS-LOCK key on. Solution: include sequences for <Control-Key-C> <Control-Key-V> and <Control-Key-X> (upper case key letters) to the respective virtual bindings to allow bindings on these events to operate independent of CAPS-LOCK position. Tested on Windows (XP) version 8.4.14.


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

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

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

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

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

  Thanks.


tkt_uuid: 2118142fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5.4
resolution: None
title: unexpected radiobutton selection behavior
comment:
  The following code operates differently between tk 8.4 and 8.5.

  Under 8.4, the 3 button frame appears with the first entry having a green background, but no button selected.

  Under 8.5, the first button having a green background, the first two buttons have a red dot but no black dot indicating selection, and the third button having the round button indicator, with no color inside the circle.

  Note that if I then move the mouse over the first button of the application, that circle changes from being red to being a round button with a black center, but still dim.

  I am unable to determine if this strange situation of having things change like this is intentional behavior by Tk or a bug.

  The code is simple:
  package require Tk

  wm title . [info tclversion]

     frame .frame
     pack .frame

     wm title . "Ex.1: [info tclversion]"

     frame .frame.typ
     pack .frame.typ

     set mcolor bisque
     set acolor green

     radiobutton .frame.typ.rad1 -relief raised -text "" -font 7x13bold \
          -width 12 -selectcolor red -anchor w -variable radio1 -value "radio1" -b
  ackground $mcolor -activebackground $acolor      -state active
     radiobutton .frame.typ.rad2 -relief raised -text "" -font 7x13bold \
          -width 12 -selectcolor red -anchor w -variable radio2 -value "radio2" -b
  ackground $mcolor -activebackground $acolor      -state normal
     radiobutton .frame.typ.rad3 -relief raised -text "" -font 7x13bold \
          -width 12 -selectcolor red -anchor w -variable radio3 -value "radio3" -b
  ackground $mcolor -activebackground $acolor      -state disabled

     pack .frame.typ.rad1 -side top
     pack .frame.typ.rad2 -side top
     pack .frame.typ.rad3 -side top


tkt_uuid: 2122502fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 30. Color Names
priority: 5 Medium
foundin: None
resolution: Fixed
title: matching colors in X11 and xcolors.c
comment:
  tk claims to support xlib color names, but /usr/share/X11/rgb.txt contains "crimson" which is missing from xlib/xcolors.c in tk sources.

  There may be other mismatches. xcolors.c should be regenerated from X11's current rgb.txt.


tkt_uuid: 2123813fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.6a2
resolution: Fixed
title: listbox manual references non-existent ttk_listbox
comment:
  The bottom of the listbox manuals says to see also ttk_listbox, which does not exist in my installation.


tkt_uuid: 2128087fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: None
title: menubutton menu-traversal shortkeys doesn't work
comment:
  Please run by wish the following script under win32. The menu-traversal shortkey
  doesn't work, but it works fine under linux :)

  Thank you all.

  lz_ufo@tin.it


  #################################################################################
  #!/usr/bin/wish

  frame .f
  pack .f -fill x

  frame .f2
  pack .f2


  # the "-underline 0" switch should create a menu-traversal shortkey.
  # Then using alt-f we aspect to open the menu.
  # It works in linux, but not in win32 :(
  #
  menubutton .f.mb -text "File" -underline 0 -menu .f.mb.m

  menu .f.mb.m -tearoff 0


  .f.mb.m add command -label "dummy" -underline 0 -command {
  }

  .f.mb.m add command -label "exit" -underline 0 -command {
          exit
  }

   
  pack .f.mb -side left

  label .f2.l -text "sample"
  pack .f2.l -side bottom


  focus -force .f
  update
  ##########################################################


tkt_uuid: 2128972fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 75. wish
priority: 7 High
foundin: obsolete: 8.5.4
resolution: None
title: wish 8.5.4 core dump
comment:
  platform: sparc solaris 9
  tcl/tk: 8.5.4

  A developer emailed me today, asking why their tcl application was core dumping.  I stopped by, and here is what I found.

  The application - assignee_edit - a purely tcl script - began:

  #! /vol/tclsrcsol/tcl85test/bin/wish8.5 -f

  :tk and tcl code

  The core file says:
  dbx /vol/tclsrcsol/tcl85test/bin/wish8.5 core 
  For information about new features see `help changes'
  To remove this message, put `dbxenv suppress_startup_message 7.0' in your .dbxrc 
  Reading wish8.5
  dbx: core object name "assignee_edit" doesn't match object name "wish8.5"
  core file ignored. 
  Use -f to force loading of corefile
  :
  :
  So, I typed:
  $ dbx -f /vol/tclsrcsol/tcl85test/bin/wish8.5 core 
  For information about new features see `help changes'
  To remove this message, put `dbxenv suppress_startup_message 7.0' in your .dbxrc 
  Reading wish8.5 core file 
  header read successfully 
  Reading ld.so.1 
  Reading libtk8.5.so 
  Reading libtcl8.5.so 
  Reading libX11.so.4 
  Reading libXext.so.0 
  Reading libdl.so.1 
  Reading libsocket.so.1 
  Reading libnsl.so.1 
  Reading libm.so.1 
  Reading libc.so.1 
  Reading libmp.so.2 
  Reading libc_psr.so.1 
  Reading libtclx8.4.so 
  Reading libOratcl4.4.so 
  Reading libclntsh.so.9.0 
  Reading libwtc9.so 
  Reading libgen.so.1 
  Reading libsched.so.1 
  Reading libaio.so.1 
  Reading librt.so.1 
  Reading libmd5.so.1 
  Reading libmd5_psr.so.1 
  program terminated by signal SEGV (no mapping at the fault address) 
  Current function is Tcl_NextHashEntry
    587           if (searchPtr->nextIndex >= tablePtr->numBuckets) {
  (dbx) where
  =>[1] Tcl_NextHashEntry(searchPtr = 0xffbfdc68), line 587 in "tclHash.c"
    [2] Tcl_FirstHashEntry(tablePtr = (nil), searchPtr = 0xffbfdc68), line 553 in "tclHash.c"
    [3] Oratcl_Clean(clientData = 0x6a478), line 217 in "oratcl.c"
    [4] Oratcl_Exit(clientData = 0x6a478), line 274 in "oratcl.c"
    [5] Tcl_Finalize(), line 949 in "tclEvent.c"
    [6] Tcl_Exit(status = 0), line 828 in "tclEvent.c"
    [7] Tk_MainEx(argc = -1, argv = 0xffbfe0f0, appInitProc = 0x114c8 = &Tcl_AppInit(Tcl_Interp *interp), interp = 0x2abc0), line 325 in "tkMain.c"
    [8] main(argc = 3, argv = 0xffbfe0e4), line 68 in "tkAppInit.c"

  Now, looking at the stack trace, one might think "hmm, probably an Oratcl error".

  Here's the kicker.

  For grins, I changed the script to read:

  #! /vol/tclsrcsol/tcl85test/bin/tclsh8.5

  package require Tk

  and now the program does not generate the core dump.

  Also, I have written the script:

  #! /vol/tclsrcsol/tcl85test/bin/wish8.5 -f
  pack [button .quit -text Quit -command exit}

  and it runs without a core dump, so it doesn't seem like the length of the magic line is the issue.


tkt_uuid: 2148529fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 16. [scrollbar]
priority: 7 High
foundin: obsolete: 8.5.4
resolution: None
title: Canvas scrolls when scrollbar indicates that it cannot.
comment:
  Description:

  In a canvas widget, when the scrollregion is smaller than the allocated window space (width/height), then a scrollbar attached to it that (as it should) indicates that the canvas cannot be scrolled, can still be used to scroll it if the user attempts it anyway (e.g. by clicking the right scrollbar button in the following example).

  This is primarily a usability inconsistency.

  Proof-of-concept:

  grid [tk::canvas .c -width 200 -height 200 -scrollregion "0 0 50 50" -xscrollcommand ".h set"]
  grid [tk::scrollbar .h -orient horizontal -command ".c xview"] -column 0 -row 1 -sticky we
  .c create rectangle 0 0 30 30 -tags rect

  Version Information:

  Tcl Version 8.5.1
  Tk Version 8.5.4
  X Window System Version 7.2.0
  X Protocol Version 11, Revision 0, Release 7.2
  OS: OpenSuse 10.3

  % array get tcl_platform
  osVersion 2.6.22.18-0.2-default pointerSize 8 byteOrder littleEndian threaded 1 machine x86_64 platform unix os Linux user alex wordSize 8

  Contact Information:

  alsterg@gmail.com


tkt_uuid: 2149109fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.4
resolution: None
title: Wish unable to get focus if started from script
comment:
  Mac OS X Tiger only! It's fine on Leopard.

  If Wish is started repeatedly from a startup (shell) script, it cannot get application focus the second time (and subsequent times) it's started.
  This becomes a problem for an application that uses a shell script to restart a server regularly.

  Replications steps on Tiger, with a 8.5.4 Wish:
  - Place the attached StartupScript shell script as "Wish.app/Contents/MacOS/StartupScript", and give it execute privileges (chmod +x StartupScript).
  - Place the attached AppMain.tcl as "Wish.app/Contents/Resources/Scripts/AppMain.tcl".
  - Double-click on Wish. Application focus is as expected.
  - Press the "Restart" button, causing the application to exit and the StartupScript to start it again.

  Happens:
  It's impossible to get Wish into the foreground (to give it focus). So no buttons can be pressed anymore, except the X in the top-left corner.

  The contents of the startup script:
  ----------------------------
  #!/bin/sh

  here="${0%/*}"
  cmd='Wish'
  ulimit -S -n 1024
  i=0
  while [ $i -eq 0 -o -f "$here/../../.restart" ]
  do
  "$here/$cmd"
  i=`expr $i + 1`
  done
  ----------------------------


tkt_uuid: 2153647fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: None
title: unreliable scrollbar tests
comment:
  When the scrollbar.test file is
  run alone, sometimes these tests
  fail:

  ==== scrollbar-3.36 ScrollbarWidgetCmd procedure, "fraction" option FAILED
  ==== Contents of test case:

      format {%.6g} [.s fraction 4 179]

  ---- Result was:
  0.98773
  ---- Result should have been (exact matching):
  1
  ==== scrollbar-3.36 FAILED



  ==== scrollbar-3.38 ScrollbarWidgetCmd procedure, "fraction" option FAILED
  ==== Contents of test case:

      format {%.6g} [.s fraction 4 178]

  ---- Result was:
  0.981595
  ---- Result should have been (exact matching):
  0.993711
  ==== scrollbar-3.38 FAILED



  ==== scrollbar-6.12 ScrollbarPosition procedure FAILED
  ==== Contents of test case:

      .s identify 8 19

  ---- Result was:
  trough1
  ---- Result should have been (exact matching):
  arrow1
  ==== scrollbar-6.12 FAILED



  ==== scrollbar-6.29 ScrollbarPosition procedure FAILED
  ==== Contents of test case:

      .s identify 8 180

  ---- Result was:
  trough2
  ---- Result should have been (exact matching):
  arrow2
  ==== scrollbar-6.29 FAILED



  ==== scrollbar-6.35 ScrollbarPosition procedure FAILED
  ==== Contents of test case:

      .s identify 18 100

  ---- Result was:

  ---- Result should have been (exact matching):
  trough2
  ==== scrollbar-6.35 FAILED


  I haven't been able to isolate the cause, but
  it has something to do with interpretation
  of coordinate values relative to the coords
  of the scrollbar widget.  These are sensitive
  to context and/or history in a way that makes
  the tests unreliable.


tkt_uuid: 2155237fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.4
resolution: Wont Fix
title: ttk::entry test independence
comment:
  in tests/ttk/entry.test, test
  entry-3.0 defines a number of
  variables which later tests
  need in order to pass, or even
  run without error.  When testing
  options cause entry-3.0 to be
  skipped, things break.

  Tests should be independent.


tkt_uuid: 2155335fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.6a2
resolution: None
title: tests substantively changed. Why?
comment:
  The 2008-07-22 commit to entry.test has
  the simple log message "Update to tcltest2".

  But that's not all that happened.  Several
  tests were re-named/re-numbered, which is
  bad, but I believe I can correct that.

  Some other tests were changed in substantive
  ways without any comment about why.  As one
  example, test entry-2.3 was:

  test entry-2.3 {Tk_EntryCmd procedure} {
      catch {destroy .e}
      entry .e
      list [winfo exists .e] [winfo class .e] [info commands .e]
  } {1 Entry .e}


  And now it is:

  test entry-2.3 {Tk_EntryCmd procedure} -body {
      entry .e
      pack .e
      update
      list [winfo exists .e] [winfo class .e] [info commands .e]
  } -cleanup {
      destroy .e
  } -result {1 Entry .e}

  I like the improved formatting and use
  of features of tcltest 2.  But what are
  those additions of [pack] and [update]
  doing in there?  Adding those changes
  the nature of what is being tested.  This
  is only one simple example.

  I want to change these back to remain
  consistent with what's been tested in
  the past, but I do not know whether making
  such changes will undo some bug fix which
  is behind making the change in the first
  place.  This is why good commit comments
  are so important.  It's not only good
  to have a record of what changed, but also
  why it was changed.


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

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

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

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


  kind regards, uwe


tkt_uuid: 2160206fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 8
foundin: obsolete: 8.5.7
resolution: None
title: Menubutton causing panic (Tk_MoveToplevelWindow)
comment:
  The following script causes a panic with Tk 8.4.x and Tk 8.5.4:

  menubutton .mb -text test
  pack .mb 
  menu .mb.menu -type menubar
  .mb configure -menu .mb.menu

  The script is probably not meaningful, but IMHO shouldn't dump core.
  (I discovered this bug trying out the "menubug" script in the Perl/Tk distribution)

  Regards,
      Slaven


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

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

  This test was expecting:
  main.test

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

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

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

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


tkt_uuid: 2168768fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 37. [tk_get*File]
priority: 9 Immediate
foundin: None
resolution: Fixed
title: tk_get*File -typevariable should be global
comment:
  The tk_get*File -typevariable is currently not well resolved. On Windows, when giving a non-qualified variable name, it reads from a local variable, but it writes back to a global variable with the same name. On Linux, it always tries to access a local variable, but of course this fails during a callback (i.e. when clicking "Open"), with the following message:
  bad level "4"
      while executing
  "upvar 4 $data(-typevariable) initialTypeName"

  The attached patch fixes this by always accessing a global variable for -typevariable.

  On Windows, it also fixes another bug with -filetypes (filterIndex was not properly initalized in tkWinDialog.c).


tkt_uuid: 2175411fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.5
resolution: Fixed
title: test ttk-6.3 lacks important control
comment:
  test ttk-6.3 "Test package cleanup" -body {
      interp create foo
      foo eval { if {[catch {package require Tk}]} { load {} Tk } }
      foo eval { destroy . }
      interp delete foo
  }

  The [package require Tk] is influenced
  by so many factors, there's no telling
  what this test will actually be testing.
  The versions and variants of Tk that
  happen to be installed as well as the
  value of environment variables like
  TCLLIBPATH fill this test with uncertainties.

  If the aim is to test the same Tk library
  that the test suite is already testing,
  it's simpler and more predictable to
  replace the line

      foo eval { if {[catch {package require Tk}]} { load {} Tk } }

  with

      load {} Tk foo

  The particular failure I encountered
  that led me to file this report, is
  that I was testing in a --enable-symbols=mem
  --enable-threads Tcl interpreter, and the
  uncontrolled [package require Tk] in this
  test brought in a libtk that was not a
  --enable-symbols=mem build, and that
  combination leads to panics.


tkt_uuid: 217791ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
priority: 1 Zero
resolution: Duplicate
title: Eliminate Tk_Uids
comment:
  OriginalBugID: 874 Bug
  Version: 8.0.3
  SubmitDate: '1998-11-25'
  LastModified: '1999-01-04'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: rjohnson
  RelatedBugIDs: 751
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '2000-10-25'
  FixedInVersion: NA
  ClosedDate: '1999-01-04'


  Date: Wed, 14 Oct 1998 17:17:14 -0700
  To: bugs@scriptics.com
  From: John Ousterhout <ouster@scriptics.com>
  Subject: Bug/RFE: eliminate Tk_Uids

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

    -John-


tkt_uuid: 2178820fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 9 Immediate
foundin: obsolete: 8.6a4
resolution: Fixed
title: Ttk depends on ckalloc(0) being non-NULL.
comment:
  When testing Tk with the cvs HEAD using Electric Fence I found that Ttk is calling ckalloc(0) on startup of wish8.6, without any widgets created.  It's just a simple wish8.6 exec.

  (gdb) where
  #0  0xb7f2e410 in __kernel_vsyscall ()
  #1  0xb797f4b6 in kill () from /lib/tls/i686/cmov/libc.so.6
  #2  0xb7f19c54 in EF_Abort () from /usr/lib/libefence.so.0
  #3  0xb7f1971b in memalign () from /usr/lib/libefence.so.0
  #4  0xb7f1988b in malloc () from /usr/lib/libefence.so.0
  #5  0xb7c9fec1 in TclpAlloc (numBytes=0) at /home/george/cvs/anon/tcl/unix/../generic/tclAlloc.c:706
  #6  0xb7cafc91 in Tcl_Alloc (size=0) at /home/george/cvs/anon/tcl/unix/../generic/tclCkalloc.c:1019
  #7  0xb7ec5556 in NewElementImpl (name=0xb4fa8ffc "", specPtr=0xb7f1462c, clientData=0x0)
      at /home/george/cvs/anon/tk/unix/../generic/ttk/ttkTheme.c:247
  #8  0xb7ec650e in Ttk_RegisterElement (interp=0xb789bcd0, theme=0xb4fa2f7c, name=0xb4fa8ffc "", 
      specPtr=0xb7f1462c, clientData=0x0)
      at /home/george/cvs/anon/tk/unix/../generic/ttk/ttkTheme.c:906
  #9  0xb7ec7ea1 in Ttk_StylePkgInit (interp=0xb789bcd0)
      at /home/george/cvs/anon/tk/unix/../generic/ttk/ttkTheme.c:1728
  #10 0xb7eb8612 in Ttk_Init (interp=0xb789bcd0)
      at /home/george/cvs/anon/tk/unix/../generic/ttk/ttkInit.c:271
  #11 0xb7e22b15 in Initialize (interp=0xb789bcd0)
      at /home/george/cvs/anon/tk/unix/../generic/tkWindow.c:3207
  #12 0xb7e22127 in Tk_Init (interp=0xb789bcd0)
      at /home/george/cvs/anon/tk/unix/../generic/tkWindow.c:2846
  #13 0x0804883e in Tcl_AppInit (interp=0xb789bcd0)
      at /home/george/cvs/anon/tk/unix/../unix/tkAppInit.c:98
  #14 0xb7e0dd8c in Tk_MainEx (argc=-1, argv=0xbfae0108, appInitProc=0x8048808 <Tcl_AppInit>, 
      interp=0xb789bcd0) at /home/george/cvs/anon/tk/unix/../generic/tkMain.c:258
  #15 0x080487f8 in main (argc=1, argv=0xbfae0104)
      at /home/george/cvs/anon/tk/unix/../unix/tkAppInit.c:68


  (gdb) frame 7
  #7  0xb7ec5556 in NewElementImpl (name=0xb4fa8ffc "", specPtr=0xb7f1462c, clientData=0x0)
      at /home/george/cvs/anon/tk/unix/../generic/ttk/ttkTheme.c:247
  (gdb) print elementImpl->nResources
  $1 = 0


  elementImpl->defaultValues = (Tcl_Obj**)
          ckalloc(elementImpl->nResources * sizeof(Tcl_Obj *));

  This seems like it will require some sort of fix throughout the ttkTheme.c, or the requirement of providing nResources > 0.


tkt_uuid: 2180919fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 56. [grab]
priority: 4
foundin: None
resolution: Fixed
title: tkBusy.c contains platform-specific code
comment:
  Right now, the platform-specific parts of [tk busy] are in the same file as the generic parts. They should be split apart.


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

  These tests are failing:

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

      tk busy configure .f -invalidOption

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



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

      tk busy configure .f -cursor nonExistingCursor

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


tkt_uuid: 2182522fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: Ttk combobox fails to restore grab.
comment:
  With the code below, the combobox bindings fail to restore the grab after the user opens up the combobox list and then discards it again by clicking somewhere outside the list. The grab is restored correctly if one of the list items is selected.

  The Quit button on top2 should never be active, but the button will work when clicked after opening and closing the combobox list without making a selection.

  wm withdraw .
  frame .tree1

  toplevel .tree1.top
  ttk::combobox .tree1.top.box -state readonly \
    -values {"Option 1" "Option 2" "Option 3"}
  button .tree1.top.quit -text Quit -command exit

  grid .tree1.top.box -padx 8 -pady 8 -sticky nwe
  grid .tree1.top.quit -padx 8 -pady 8

  toplevel .top2
  button .top2.quit -text Quit -command exit
  grid .top2.quit -padx 8 -pady 8

  grab .tree1

   
  Issue found on SuSE linux 11.0 with tcl/tk 8.5.4


tkt_uuid: 2184632fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: None
resolution: None
title: postcascade <index> does not work
comment:
  Explicitly calling postcascade to attempt to pop up a menu from the menubar does on work.  Tested on OS X 10.5, Tcl/Tk 8.4.7, 8.6a1:


  menu .mbar -tearoff 0
  . configure -menu .mbar
  menu .mbar.apple -tearoff 0
  .mbar add cascade -menu .mbar.apple
  .mbar.apple add command -label "About Foo" -command { puts "About" }
  menu .mbar.file -tearoff 0
  .mbar.file add command -label "Dummy" -command { puts "Dummy" }
  .mbar add cascade -label "File" -menu .mbar.file

  after 5000 { .mbar postcascade 0 }


  Nothing happens, and no error is generated.

  (The use case for calling this in user code is to simulate platform compliance using bindings, for the following: Command-? activates Help menu, Control-F2 activates Apple menu.)


tkt_uuid: 2191960fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: obsolete: 8.6a4
resolution: Fixed
title: tests use identity encoding
comment:
  A few tests in unixSelect.test
  make use of the "identity"
  encoding.

  Test winClipboard-1.5 uses the
  command [tcltest::bytestring]
  which is based on the "identity"
  encoding.

  These tests are old.  Hoping there's
  someone who can comment on what
  they're meant to test.  Furthermore
  whether the same testing objective
  can be met using some part of Tcl
  that we actually want to keep around. :)


tkt_uuid: 219218ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 7 High
foundin: obsolete: 8.3.2
resolution: Fixed
title: error handling with bgerror in Tk
comment:
  OriginalBugID: 3998 Bug
  Version: 8.2.3
  SubmitDate: '2000-01-10'
  LastModified: '2000-01-23'
  Severity: MED
  Status: Assigned
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2577 2136 750
  OS: All
  FixedDate: '2000-10-25'
  ClosedDate: '2000-10-25'


  Name:
  Torsten Rottmann

  ReproducibleScript:
  wish
  % after 1 dfdf
  after#0
  % bgerror failed to handle background error.
      Original error: invalid command name "dfdf"
      Error in bgerror: invoked "break" outside of a loop

  ObservedBehavior:
  If you press "Skip Messages" ( the "return -code break" behaviour) former version of Tcl
  didn't complain about "break outside a loop"

  DesiredBehavior:
  Same as in Tcl8.0: nothing



  This behavior seems to have changed between 8.0.4 and 8.1. 
  -- 01/23/2000 hobbs


tkt_uuid: 219373ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 7 High
resolution: None
title: Tcl core dumps after several hours
comment:
  OriginalBugID: 5995 Bug
  Version: 8.3.1
  SubmitDate: '2000-07-10'
  LastModified: '2000-07-17'
  Severity: CRIT
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: ericm
  OS: Windows NT
  OSVersion: Windows NT 4.0
  Machine: Dell Dimension XPST550, 128M RAM
  FixedDate: '2000-10-25'
  ClosedDate: '2000-10-25'


  Name:
  Yukari Cash

  Extensions:
  Tix 4.1.8.2  from Iain Findleton

  CustomShell:
  None.

  Comments:
  The problem occurs with tcl/tk 8.2.x and tcl/tk 8.3.1.  
      The problem did not occur with tcl/tk8.0.

      This is an urgent matter, as we have customers waiting for the new
      version of our application.  We are unable to release the new version as
      long as tcl/tk core dumps.

  ReproducibleScript:
  Our application is very large and it would be difficult for you to replicate the problem without special test equipment.  If necessary, I could provide a sample application which recreates the problem without the need for any special equipment.  This won't be easy, so I'm hoping the stack trace is sufficient to identify the problem.

  ObservedBehavior:
  Our application uses Tcl/Tk and users run the application anywhere from a few minutes to overnight.  The application runs fine up to 1.5 to 2 hours.  After several hours (approximately 2 hours), Tcl/Tk core dumps with, for example:
  "Instruction at 0x0099a07f referenced memory at 0x00000000. The memory could not be read."

  Here is the stack trace:
  TkWinGetDrawableDC(_XDisplay * 0x00177a18, unsigned long 0, TkWinDCState * 0x0012c994) line 158 + 3 bytes
  XCopyArea(_XDisplay * 0x00177a18, unsigned long 0, unsigned long 45575632, XGCValues * 0x023d4640, int 30, int 30, unsigned int 56, unsigned int 530, int 32, int 1) line 317 + 17 bytes
  DisplayCanvas(int * 0x02a1abd0) line 2364 + 95 bytes
  TclServiceIdle() line 692 + 12 bytes
  Tcl_DoOneEvent(int -1) line 923 + 5 bytes
  Tk_UpdateObjCmd(int * 0x0014d7b8, Tcl_Interp * 0x001449a8, int 1, Tcl_Obj * const * 0x00154a08) line 889 + 16 bytes
  TclExecuteByteCode(Tcl_Interp * 0x001449a8, ByteCode * 0x03c57cb0) line 846 + 34 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x001449a8, Tcl_Obj * 0x02924418, int 0) line 2733 + 13 bytes
  TclObjInterpProc(int * 0x02924718, Tcl_Interp * 0x001449a8, int 6, Tcl_Obj * const * 0x001549f0) line 1001 + 21 bytes
  TclExecuteByteCode(Tcl_Interp * 0x001449a8, ByteCode * 0x03bf2bf0) line 846 + 34 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x001449a8, Tcl_Obj * 0x02923898, int 0) line 2733 + 13 bytes
  TclObjInterpProc(int * 0x02923998, Tcl_Interp * 0x001449a8, int 3, Tcl_Obj * const * 0x0012d864) line 1001 + 21 bytes
  EvalObjv(Tcl_Interp * 0x001449a8, int 3, Tcl_Obj * const * 0x0012d864, char * 0x039388a0, int 26, int 0) line 932 + 25 bytes
  Tcl_EvalEx(Tcl_Interp * 0x001449a8, char * 0x039388a0, int 26, int 262144) line 1393 + 30 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x001449a8, Tcl_Obj * 0x03aecc00, int 262144) line 2580 + 21 bytes
  Tcl_UplevelObjCmd(int * 0x00000000, Tcl_Interp * 0x001449a8, int 1, Tcl_Obj * const * 0x001549ec) line 604 + 20 bytes
  TclExecuteByteCode(Tcl_Interp * 0x001449a8, ByteCode * 0x038caf40) line 846 + 34 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x001449a8, Tcl_Obj * 0x028fc3e0, int 0) line 2733 + 13 bytes
  TclObjInterpProc(int * 0x028fc9e0, Tcl_Interp * 0x001449a8, int 2, Tcl_Obj * const * 0x001549e0) line 1001 + 21 bytes
  TclExecuteByteCode(Tcl_Interp * 0x001449a8, ByteCode * 0x03becbe0) line 846 + 34 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x001449a8, Tcl_Obj * 0x02313a40, int 0) line 2733 + 13 bytes
  TclObjInterpProc(int * 0x02313840, Tcl_Interp * 0x001449a8, int 2, Tcl_Obj * const * 0x001549d8) line 1001 + 21 bytes
  TclExecuteByteCode(Tcl_Interp * 0x001449a8, ByteCode * 0x03c02410) line 846 + 34 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x001449a8, Tcl_Obj * 0x023137c0, int 0) line 2733 + 13 bytes
  TclObjInterpProc(int * 0x023135c0, Tcl_Interp * 0x001449a8, int 1, Tcl_Obj * const * 0x001549d4) line 1001 + 21 bytes
  TclExecuteByteCode(Tcl_Interp * 0x001449a8, ByteCode * 0x03a95dd0) line 846 + 34 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x001449a8, Tcl_Obj * 0x02a6b670, int 131072) line 2733 + 13 bytes
  TkInvokeButton(TkButton * 0x02a195c0) line 1467 + 33 bytes
  ButtonWidgetObjCmd(int * 0x02a195c0, Tcl_Interp * 0x001449a8, int 2, Tcl_Obj * const * 0x03cb6bb0) line 842 + 9 bytes
  EvalObjv(Tcl_Interp * 0x001449a8, int 2, Tcl_Obj * const * 0x03cb6bb0, char * 0x0098443c, int 0, int 262144) line 932 + 25 bytes
  Tcl_EvalObjv(Tcl_Interp * 0x001449a8, int 2, Tcl_Obj * const * 0x03cb6bb0, int 262144) line 1019 + 32 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x001449a8, Tcl_Obj * 0x03ac6730, int 262144) line 2576 + 27 bytes
  Tcl_UplevelObjCmd(int * 0x00000000, Tcl_Interp * 0x001449a8, int 1, Tcl_Obj * const * 0x001549d0) line 604 + 20 bytes
  TclExecuteByteCode(Tcl_Interp * 0x001449a8, ByteCode * 0x038d6d50) line 846 + 34 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x001449a8, Tcl_Obj * 0x00226138, int 0) line 2733 + 13 bytes
  TclObjInterpProc(int * 0x002261b8, Tcl_Interp * 0x001449a8, int 2, Tcl_Obj * const * 0x0012f8bc) line 1001 + 21 bytes
  EvalObjv(Tcl_Interp * 0x001449a8, int 2, Tcl_Obj * const * 0x0012f8bc, char * 0x0012fad4, int 34, int 0) line 932 + 25 bytes
  Tcl_EvalEx(Tcl_Interp * 0x001449a8, char * 0x0012fad4, int 34, int 0) line 1393 + 30 bytes
  Tcl_Eval(Tcl_Interp * 0x001449a8, char * 0x0012fad4) line 1512 + 17 bytes
  Tcl_GlobalEval(Tcl_Interp * 0x001449a8, char * 0x0012fad4) line 4149 + 13 bytes
  Tk_BindEvent(Tk_BindingTable_ * 0x001479a8, _XEvent * 0x03b956d8, Tk_Window_ * 0x02a169c0, int 0, int * * 0x0012fbf4) line 1775 + 23 bytes
  TkBindEventProc(TkWindow * 0x02a169c0, _XEvent * 0x03b956d8) line 245 + 31 bytes
  Tk_HandleEvent(_XEvent * 0x03b956d8) line 737 + 13 bytes
  WindowEventProc(Tcl_Event * 0x03b956d0, int -3) line 1072 + 12 bytes
  Tcl_ServiceEvent(int -3) line 607 + 11 bytes
  Tcl_DoOneEvent(int -3) line 910 + 9 bytes
  Tk_MainLoop() line 1130 + 13 bytes
  Tk_MainEx(int 1, char * * 0x00134770, int (Tcl_Interp *)* 0x0042fb8e Tcl_AppInit(Tcl_Interp *), Tcl_Interp * 0x001449a8) line 282
  WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00132a5f, int 1) line 150 + 26 bytes
  WinMainCRTStartup + 319 bytes
  KERNEL32! 77f1b9ea()

  DesiredBehavior:
  No core dumps.



  We need more information.  Can you tell us what is being displayed on the canvas at the time of the crash, and give us a general feel for what the application is doing?

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

  -- 07/17/2000 ericm


tkt_uuid: 219386ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Works For Me
title: Test failures on Solaris2.6
comment:
  OriginalBugID: 6115 Bug
  Version: 8.3.1
  SubmitDate: '2000-08-10'
  LastModified: '2000-10-25'
  Severity: CRIT
  Status: UnAssn
  Submitter: techsupp
  OS: Solaris
  OSVersion: 2.6
  Machine: Ultra 5
  FixedDate: '2000-10-25'
  ClosedDate: '2000-10-25'


  Name:
  Larry W. Virden

  Extensions:
  Tk

  CustomShell:
  None - this is the tk 8.3.2 from the

  ReproducibleScript:
  make test

  ObservedBehavior:
  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 {selection get -s CLIPBOARD 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

  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

  unixEmbed.test
  X Error of failed request:  BadValue (integer parameter out of range for operati
  on)
    Major opcode of failed request:  53 (X_CreatePixmap)
    Value in failed request:  0x8
    Serial number of failed request:  115821
    Current serial number in output stream:  115824
  make: *** [test] Error 1

  At this point the tktest process hangs.

  DesiredBehavior:
  all tests succeed.


tkt_uuid: 219404ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
resolution: Works For Me
title: Wish crashes under Win2K
comment:
  OriginalBugID: 6314 Bug
  Version: 8.0.3
  SubmitDate: '2000-09-26'
  LastModified: '2000-10-25'
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  OS: Windows 2000
  OSVersion: Windows 2000
  Machine: Pentium III 500, 256MB RAM, 10GB HDD
  FixedDate: '2000-10-25'
  ClosedDate: '2000-10-25'


  Name:
  Connie van Zyl

  Extensions:
  TCL

  CustomShell:
  None.

  ReproducibleScript:
  When running wish.exe under Windows 2000, it creates a Dr. Watson error.  The software I'm using actually uses Tcl 7.5 source code.  I'm not doing any programming with Tcl myself, but I nned to get this wish problem sorted out as soon as possible.


tkt_uuid: 219419ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Fixed
title: Canvas stippled line bugs
comment:
  OriginalBugID: 6368 Bug
  Version: 8.3.2
  SubmitDate: '2000-10-16'
  LastModified: '2000-10-16'
  Severity: SER
  Status: UnAssn
  Submitter: angie
  ChangedBy: angie
  OS: All
  OSVersion: all
  FixedDate: '2000-10-25'
  ClosedDate: '2000-10-25'


  Tk 8.3.2 Bug

  Support:  None
  Severity:  2
  OperatingSystem:  All
  Synopsis:  Canvas stippled line bugs

  ObservedBehavior:
  1. Option "disabledwidth" is not taken into account for drawing.
  2. Options "activewidth" and "disabledwidth" are taken into account only when bigger than the normal width.
  3. Stippled lines with width 1 are not (or not completely) drawn on Windows.

  Patch:
  1. Change "activeWidth" to "disabledWidth" in line 880 of tkCanvLine.c (tk8.3.2)
  2. Change ">linewidth" to "!=linewidth" in lines 872 and 879 of tkCanvLine.c (tk8.3.2)
  3. Delete lines 751 and 756 of tkWinDraw.c (tk8.3.2).
  4. Apply similar patches to tk8.4a1.
  Posted To comp.lang.tcl: Posted Successfully


tkt_uuid: 219842ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: can't fill canvas object with a stipple
comment:
  OriginalBugID: 555 Bug
  Version: 8.0p2
  SubmitDate: '1998-03-31'
  LastModified: '1999-08-14'
  Severity: LOW
  Status: Closed
  Submitter: hershey
  ChangedBy: hobbs
  RelatedBugIDs: 1274 1379
  OS: Macintosh
  OSVersion: 8.1
  Machine: NA
  FixedDate: '2000-10-30'
  FixedInVersion: NA
  ClosedDate: '1999-08-14'


  From: "David A. Smith" <dasmith@perseus.tufts.edu>
  Newsgroups: comp.lang.tcl
  Subject: BUG: Stipple on the Mac
  Date: Thu, 26 Mar 1998 12:36:06 -0500

  I seem to remember that it's a known bug that the Mac can't fill canvas
  objects with a stipple. Any idea if and when this will be fixed. Using
  Tk8.0p2 on MacOS 8.1, the following will reproduce the bug:

  canvas .c
  pack .c
  set id [.c create rectangle 100 100 200 200 -fill red]
  .c itemconfigure $id -stipple gray 50

  The rectangle remains a solid red.

  Stippling is known to not work on Mac/Windows. 
  -- 08/06/1999 hobbs


tkt_uuid: 219843ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: porting problem between 7.6 and 8.0 in Tk_CoordsToWindow
comment:
  OriginalBugID: 568 Bug
  Version: 8.0p2
  SubmitDate: '1998-04-15'
  LastModified: '1999-08-14'
  Severity: SER
  Status: Closed
  Submitter: hershey
  ChangedBy: hobbs
  RelatedBugIDs: 716
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '2000-10-30'
  FixedInVersion: NA
  ClosedDate: '1999-08-14'


  >I moved from tk7.6 to tk8.0p2 within my graphical application.
  >My application consist of an opengl widget within Tk.
  >
  >When interacting with my widget, I sometimes get the message :
  >
  >"Tk_CoordsToWindow got False return from XTranslateCoordinates"
  >
  >which makes my application abort.
  >I never got this message with tk7.6.
  >
  >Looking into the sources (in tk8.0/unix/tkUnixWm.c) I found that the
  >implementation
  >of Tk_CoordsToWindow has changed from tk7.6 near the call to
  >XTranslateCoordinates.
  >A call to the "panic" function is made when something is wrong, which
  >makes my program abort. 
  >I have intentionally removed the "panic" line to observe that my program
  >again works
  >correctly. It seems like the implementation of Tk_CoordsToWindow is more
  >robust in
  >tk7.6.
  >-- 
  >Michel Pottiez
  >NUMECA International s.a.
  >Avenue F. Roosevelt, 5
  >B-1050 Brussels  -  BELGIUM
  >Tel    : 32 2 647 83 11
  >Fax    : 32 2 647 93 98
  >e-mail : michel@numeca.be


tkt_uuid: 219844ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: Insert in entries on Windows
comment:
  OriginalBugID: 609 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '1998-08-05'
  Severity: LOW
  Status: Closed
  Submitter: stanton
  ChangedBy: stanton
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedDate: '2000-10-30'
  FixedInVersion: NA
  ClosedDate: '1998-08-05'



   Tom Tromey <tromey@creche.cygnus.com>
  Tk 8.0 on NT 4.0.

  On Windows, the <Insert> key should do nothing in entries.
  Right now it inserts the contents of the selection.
  It also shadows the Shift-Insert key sequence (which should generate
  the <<Paste>> virtual event).

  I fixed it by removing the <Insert> binding from entry.tcl when on
  Windows.

  Tom



  duplicate of bug 52


tkt_uuid: 219895ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 1 Zero
foundin: obsolete: 8.1a2
resolution: Duplicate
title: stipple in Mac vers. 8.0 and 8.1a2
comment:
  OriginalBugID: 610 Bug
  Version: 8.1a2
  SubmitDate: '1998-05-21'
  LastModified: '1999-08-14'
  Severity: LOW
  Status: Closed
  Submitter: hershey
  ChangedBy: hobbs
  RelatedBugIDs: 555 1274
  OS: Macintosh
  OSVersion: NA
  Machine: NA
  FixedDate: '2000-10-31'
  FixedInVersion: NA
  ClosedDate: '1999-08-14'


  Dear Tk Team,

  I don't know if this is a know bug, but I cannot get canvas objects to be
  stippled on Mac OS. Using System 8.1, and Wish8.0p2 or Wish8.1a2:

  canvas .c
  pack .c
  .c create rectangle 100 100 200 200 -fill red -stipple gray50

  The above produces a solid red rectangle. Will this be fixed soon? Thanks
  for the great product!

  David Smith
  Programmer
  Perseus Project
  David Smith <dasmith@perseus.tufts.edu>


tkt_uuid: 219898ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Duplicate
title: Bug in "wm transient"
comment:
  OriginalBugID: 642 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-25'
  LastModified: '1998-06-04'
  Severity: MED
  Status: Closed
  Submitter: stanton
  ChangedBy: stanton
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedDate: '2000-10-31'
  FixedInVersion: NA
  ClosedDate: '1998-06-04'


  I think I have found a bug in the "wm transient" command.
  Try the following:

     toplevel .t
     wm withdraw .t
     wm transient .t .

  The "wm transient" command causes the toplevel to be mapped !

  The culprit seems to be a line of code in tkWInWm.c that
  handles the "wm transient" command:

  line 2056:
          /*
          * Ensure that the transient window is either mapped or 
          * unmapped like its master.
          */

          TkpWmSetState(winPtr, NormalState);

  Commenting this out seems to stop the unwanted mapping and doesn't
  have any bad side-effects as far as I can see.
  ---
  Mark Gammon                                  Tel: int+44 (0) 1223 237111
  Principal Applications Engineer              Fax: int+44 (0) 1223 234192
  FEGS Ltd, Oakington House                    e-mail: m.gammon@fegs.co.uk
  Oakington, Cambridge CB4 5AF                 web:  http://www.fegs.co.uk
  England

  This is a duplicate of bug 30.


tkt_uuid: 219899ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Duplicate
title: The Caps-Lock indicator Led don't function only in Windows 9
comment:
  OriginalBugID: 683 Bug
  Version: 8.0.3
  SubmitDate: '1998-09-24'
  LastModified: '1999-08-06'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2493
  OS: All
  OSVersion: NA
  Machine: X86
  FixedDate: '2000-10-31'
  FixedInVersion: NA
  ClosedDate: '1999-08-06'


  The Caps-Lock led functions normaly in each windows application. If i change to the prowish window, clicking to the Caps-Lock takes no effect to the keyboard led. Windows NT handles the Caps-Lock led correctly. 

  This problem is reproduced in the regular 8.0.3 wish interpreter. When in the interpreter, click the caps lock button and check the caps lock light. It is not on.


tkt_uuid: 219900ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Duplicate
title: bug in checkbutton inside cascade menu: can't traverse cascade past the checkbutton menu
comment:
  OriginalBugID: 691 Bug
  Version: 8.0p2
  SubmitDate: '1998-10-02'
  LastModified: '1999-08-13'
  Severity: MED
  Status: Closed
  Submitter: hershey
  ChangedBy: hobbs
  RelatedBugIDs: 676
  OS: All Unix
  OSVersion: NA
  Machine: NA
  FixedDate: '2000-10-31'
  FixedInVersion: NA
  ClosedDate: '1999-08-13'


  The menus do not seem to work properly under Unix.  I am running
  Tcl/Tk 8.0.2 on Redhat Linux 5.1.

  To reproduce the problems, do the following:

  Try running the widget demo and then clicking on "Menus and cascades".
  Bring up the "Cascades" menu.  Using the down arrow, move to "Check
  buttons".  As soon as you get to that menu option, the cascade menu
  pops up and you are no longer traversing the "Cascades" menu, but are
  now in the "Check buttons" menu.  You have to click the left arrow key
  to get back to the "Cascades" menu.

  This effect is really bad if the first item at the top of a menu is a
  cascade menu.  Then, just clicking the mouse to popup the overall menu
  will cause the cascade menu to popup.  Even though it was never
  selected.  There are no menus in the demos which have this, so it is
  trickier to demonstrate this, although it happens in some of my code.

  Thanks,
  Sim Harbert

  This is the defined behavior, and not really a bug.  On Windows,
  you get the behavior you expected using native menus.  Unix does
  not seem to have a standard for this (Netscape is totally messed
  up - the Linux one anyway). 
  -- 08/13/1999 hobbs


tkt_uuid: 219902ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Duplicate
title: bug in tk_getOpenFile when called before adding widgets to the "." window
comment:
  OriginalBugID: 715 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-13'
  LastModified: '1999-08-20'
  Severity: MED
  Status: Closed
  Submitter: admin
  ChangedBy: hobbs
  RelatedBugIDs: 1212
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '2000-10-31'
  FixedInVersion: NA
  ClosedDate: '1999-08-20'


  # BUG:
  # This code demonstrates an apparent bug in the grab handling of
  # tk_getOpenFile, if run at the start of a program.  If tk_getOpenFile
  # is run before adding any widgets to the "." window, the widgets in
  # the "." window will fail to respond to any events other than 
  # WM_DESTROY and resizing.  Note that this behavior is only exhibited
  # on Windows, not on Unix or MacOS.
  #
  # AFFECTED PLATFORMS:
  # - Tcl 8.0p2 & 8.0.3 on Win NT4 (SP3), Win 98, Win 95 (OSR2.5)
  #
  # UNAFFECTED PLATFORMS:
  # - Tcl 8.0p2 on Solaris 2.5
  # - Tcl 8.0.3 on Linux (Redhat 5.0)
  # - Tcl 8.0.3 on MacOS
  #
  # WORKAROUND:
  # This can be worked around by doing the tk_getOpenFile after windows
  # have been mapped, using an "after idle" as shown in the lower section
  # of this program.

  set demonstrate_bug 1

  if {$demonstrate_bug} {
      set inputFile [tk_getOpenFile -title "Choose a URL-Mapping Text File"  -filetypes {{{Text Files} {.txt}}} -initialdir [pwd]]
      label .l1 -text "Selected:" -justify left -anchor w
      label .l2 -textvariable inputFile -justify left -anchor w
      button .b -text Ok -command exit
      pack .l1 .l2 .b -side top -fill x
  } else {
      label .l1 -text "Selected:" -justify left -anchor w
      label .l2 -textvariable inputFile -justify left -anchor w
      button .b -text Ok -command exit
      pack .l1 .l2 .b -side top -fill x
      after idle {
          set inputFile [tk_getOpenFile -title "Choose a URL-Mapping Text File"  -filetypes {{{Text Files} {.txt}}} -initialdir [pwd]]
      }
  }


tkt_uuid: 219903ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Duplicate
title: bug in tk_getOpenFile when called before adding widgets to the "." window
comment:
  OriginalBugID: 715 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-13'
  LastModified: '1999-08-20'
  Severity: MED
  Status: Closed
  Submitter: admin
  ChangedBy: hobbs
  RelatedBugIDs: 1212
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-20'


  # BUG:
  # This code demonstrates an apparent bug in the grab handling of
  # tk_getOpenFile, if run at the start of a program.  If tk_getOpenFile
  # is run before adding any widgets to the "." window, the widgets in
  # the "." window will fail to respond to any events other than 
  # WM_DESTROY and resizing.  Note that this behavior is only exhibited
  # on Windows, not on Unix or MacOS.
  #
  # AFFECTED PLATFORMS:
  # - Tcl 8.0p2 & 8.0.3 on Win NT4 (SP3), Win 98, Win 95 (OSR2.5)
  #
  # UNAFFECTED PLATFORMS:
  # - Tcl 8.0p2 on Solaris 2.5
  # - Tcl 8.0.3 on Linux (Redhat 5.0)
  # - Tcl 8.0.3 on MacOS
  #
  # WORKAROUND:
  # This can be worked around by doing the tk_getOpenFile after windows
  # have been mapped, using an "after idle" as shown in the lower section
  # of this program.

  set demonstrate_bug 1

  if {$demonstrate_bug} {
      set inputFile [tk_getOpenFile -title "Choose a URL-Mapping Text File"  -filetypes {{{Text Files} {.txt}}} -initialdir [pwd]]
      label .l1 -text "Selected:" -justify left -anchor w
      label .l2 -textvariable inputFile -justify left -anchor w
      button .b -text Ok -command exit
      pack .l1 .l2 .b -side top -fill x
  } else {
      label .l1 -text "Selected:" -justify left -anchor w
      label .l2 -textvariable inputFile -justify left -anchor w
      button .b -text Ok -command exit
      pack .l1 .l2 .b -side top -fill x
      after idle {
          set inputFile [tk_getOpenFile -title "Choose a URL-Mapping Text File"  -filetypes {{{Text Files} {.txt}}} -initialdir [pwd]]
      }
  }


