# ticket

tkt_uuid: 629827ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: None
title: Moving toplevel windows fails
comment:
  Moving or resizing toplevel windows under Windows OS
  sometimes fails. This problem occured within an
  application running cyclic http calls. The attached
  code reduces the problem to a few lines of code. To
  reproduce the problem simply run the attached code
  inside a wish, drag the window to another position and
  wait until the mouse looses the window (still holding
  the left mousebutton).


tkt_uuid: 220465ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: Binding "update" in <Expose> window event prevents Windows from managing geometry
comment:
  OriginalBugID: 1600 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-23'
  LastModified: '2000-01-31'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 1601
  OS: Windows NT
  OSVersion: 4.0 SP4
  Machine: X86
  FixedDate: '2000-01-31'
  FixedInVersion: 8.3b2


  Name:
  Petasis Georgios

  ReproducibleScript:
      toplevel .t
      text .t.t
      pack .t.t
      bind .t <Expose> {update}
      
      toplevel .w
      text .w.t
      pack .w.t

  ObservedBehavior:
  Under windows only: you cannot move or resize the second window when
  overlaps
  the first. This happens only under windows (in my system NT 4.0 SP4) and
  not on unix (tested on Solaris 2.6 under KDE, CDE and Openwindows...)

  DesiredBehavior:
  Resize or move the second window without problem


  This works as expected in 8.3b2. 
  -- 01/31/2000 hobbs


tkt_uuid: 1591481fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: None
title: canvRect.test 9.1 and 10.1 failure
comment:
  Platform: built cvs head using SPARC Solaris 2.9 and
  Sun C compiler, 
  configured by ./configure, generated by GNU Autoconf 2.59, 
    with options \"'--prefix=/volws/lwv27/ldatae'
  '--enable-shared' '--enable-symbols' '--enable-stubs'
  '--enable-langinfo' 'CC=cc'\"

  (Note that tcl 8.5a5 cvs head was configured with
  threads enabled).

  Tk tests were displayed from SPARC Solaris through a
  Windows XP SP2 Intel via Hummingbird Exceed version
  10.0.0.12 .


  The following two test cases failed:
    
  canvRect.test

  ==== canvRect-9.1 ScaleRectOval procedure FAILED
  ==== Contents of test case:

      .c delete withtag all
      .c create rect 100 300 200 350 -tags x
      .c scale x 50 100 2 4
      .c coords x

  ---- Result was:
  150.0 900.0 350.0 1099.9999999999998
  ---- Result should have been (exact matching):
  150.0 900.0 350.0 1100.0
  ==== canvRect-9.1 FAILED

  ==== canvRect-10.1 TranslateRectOval procedure FAILED
  ==== Contents of test case:

      .c delete withtag all
      .c create rect 100 300 200 350 -tags x
      .c move x 100 -10
      .c coords x

  ---- Result was:
  200.0 290.0 300.0 339.99999999999994
  ---- Result should have been (exact matching):
  200.0 290.0 300.0 340.0
  ==== canvRect-10.1 FAILED


tkt_uuid: 2378039fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: None
title: treeview custom layout problems
comment:
  I tried unsuccessfully to remove the border on a Treeview. I first tried copying the default layout and changing "-border 1" to "-border 0" but that appears to have no effect (only tested this on the mac).

  If I omit the Treeview.field element entirely, it seems that the Treeview.padding and/or the Treeview.textarea elements aren't properly expanding to fill the cavity. When I remove the field element I've left with one background color surrounding the listbox elements and another that fills up the empty space after the last element.


tkt_uuid: 220838ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.1b3
resolution: Duplicate
title: font size taken wrong from X font
comment:
  OriginalBugID: 1839 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-15'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: pat
  OS: Solaris
  OSVersion: 2.5.1
  Machine: Other


  Name:
  Peter Weigand

  ReproducibleScript:
  set font "-misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-1"
      puts "[font actual $font]"
      set font "fixed 14"
      puts "[font actual $font]"

  ObservedBehavior:
  If you create a text in a canvas it is taking font size ok but when you
      create postscript it takes font size 11 and not 14.

  DesiredBehavior:
  I'd like to see size 14 for both font definitions.


tkt_uuid: 1676680fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 17. [spinbox]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: new test failures
comment:
  On Solaris 9 /CDE, these
  test failures are new since
  8.5a5. Failures happen
  in both --enable- and --disable-xft
  configurations:

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

      catch {destroy .e}
      spinbox .e -width 0
      pack .e
      .e insert end "0123"
      update
      .e configure -font $big
      update
      winfo geom .e

  ---- Result was:
  79x37+10+0
  ---- Result should have been (exact matching):
  79x37+0+0
  ==== spinbox-5.8 FAILED



  ==== spinbox-6.2 SpinboxComputeGeometry procedure FAILED
  ==== Contents of test case:

      catch {destroy .e}
      spinbox .e -font $fixed -bd 2 -relief raised -width 20 -justify center  -highlightthickness 3
      pack .e
      .e insert end 012\t45
      update
      list [.e index @96] [.e index @97]

  ---- Result was:
  6 6
  ---- Result should have been (exact matching):
  3 4
  ==== spinbox-6.2 FAILED



  ==== spinbox-6.3 SpinboxComputeGeometry procedure FAILED
  ==== Contents of test case:

      catch {destroy .e}
      spinbox .e -font $fixed -bd 2 -relief raised -width 20 -justify right  -highlightthickness 3
      pack .e
      .e insert end 012\t45
      update
      list [.e index @131] [.e index @132]

  ---- Result was:
  6 6
  ---- Result should have been (exact matching):
  3 4
  ==== spinbox-6.3 FAILED


tkt_uuid: 220383ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: incompatibility betw. Tix and 8.0.3 (with patch)
comment:
  OriginalBugID: 716 Bug
  Version: 8.0.3
  SubmitDate: '1998-10-13'
  LastModified: '1999-12-21'
  Severity: SER
  Status: Released
  Submitter: admin
  ChangedBy: hobbs
  RelatedBugIDs: 720 1355 1376 2492
  OS: All Unix
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-12-21'
  FixedInVersion: 8.3b1


  A while ago I noticed a problem when we first tried to convert to 8.0,

  and that was that the application would crash with the following error:


  > X Error of failed request:  BadWindow (invalid Window parameter)

  >   Major opcode of failed request:  40 (X_TranslateCoords)

  >   Resource id in failed request:  0x1400246

  >   Serial number of failed request:  15956

  >   Current serial number in output stream:  15956


  It seemed to be related to including Tix calls, and so I sent a message

  to the Tix mailing list to see if anyone else had encountered it.

  Other people had, and I was sent the attached patch to tkUnixWm.c.

  I applied the patch, and it worked fine.  Now, with 8.0.3, it is 

  dumping again with the same error.


  *** tkUnixWm.c.org      Thu Aug 14 00:24:53 1997

  --- tkUnixWm.c  Tue Aug 26 08:31:09 1997

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

  *** 3377,3382 ****

  --- 3377,3383 ----

                  if (root == None) {

                      root = RootWindowOfScreen(Tk_Screen((Tk_Window)winPtr));

                  }

  +

                  XTranslateCoordinates(winPtr->display, winPtr->window,

                      root, 0, 0, &rootX, &rootY, &dummyChild);

                  x += rootX;

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

  *** 3434,3439 ****

  --- 3435,3441 ----

        int x, y, childX, childY, tmpx, tmpy, bd;

        WmInfo *wmPtr;

        TkWindow *winPtr, *childPtr, *nextPtr;

  +     Tk_ErrorHandler handler;


        /*

         * Step 1: scan the list of toplevel windows to see if there is a

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

  *** 3472,3483 ****

  --- 3474,3494 ----

         *    the toplevel.

         */


  +     handler = Tk_CreateErrorHandler(Tk_Display(tkwin), -1, -1, -1,

  +           (Tk_ErrorProc *) NULL, (ClientData) NULL);

  +

        while (1) {

  +

          if (XTranslateCoordinates(Tk_Display(tkwin), parent, window,

                  x, y, &childX, &childY, &child) == False) {

  +

  +           fprintf (stderr, "Tk_CoordsToWindow got False return from

  XTranslateCoordinates\n");

  +           fflush (stderr);

  +           return NULL;

              panic("Tk_CoordsToWindow got False return from XTranslateCoordinates");

          }

          if (child == None) {

  +           Tk_DeleteErrorHandler(handler);

              return NULL;

          }

          for (wmPtr = firstWmPtr; wmPtr != NULL; wmPtr = wmPtr->nextPtr) {

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

  *** 3499,3504 ****

  --- 3510,3517 ----

        }


        gotToplevel:

  +

  +     Tk_DeleteErrorHandler(handler);

        winPtr = wmPtr->winPtr;

        if (winPtr->mainPtr != ((TkWindow *) tkwin)->mainPtr) {

          return NULL;




  The same translate problem is seen, always with Tix involved,
  from the following people:
  alan.davis@convergys.com robert.r.ratcliff@boeing.com danny.bach@boeing.com gustin@uia.ua.ac.be david.tillman@jhuapl.edu
  See related ids for more. 
  -- 08/14/1999 hobbs
  Fixed for 8.3b1. 
  -- 12/21/1999 hobbs


tkt_uuid: 220245ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Invalid
title: bindings for buttons on text not working?
comment:
  OriginalBugID: 3232 Bug
  Version: 8.0.4
  SubmitDate: '1999-10-28'
  LastModified: '1999-10-30'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Other
  OSVersion: Rh 6.0
  Machine: NA
  ClosedDate: '1999-10-30'


  Name:
  Joe Acosta

  Extensions:
  pure Tcl/Tk 8.0.4

  ReproducibleScript:
  It seems taht the Button-2 bindings are not working in the text widget.
      
      I try to use the folloing line 
      
      bind .textarea <Button-2> {mymethod}
      
      and mymethod does not get executed. However if I replace Button-2 with
      Button-1 then the method gets executed.  I searched thru the text.tcl
      code and there seems to be interactions for the Buton-2 but I am not
      sure what is happening..

  DesiredBehavior:
  Button-2 to have bindings to the text widget so that a popup menu can be
      created.



  The user is likely confusing Button-2 with Button-3.  Button-2
  is the middle mouse button on a 3 button mouse, Button-3 is the
  right mouse button.  Otherwise, I have no problem binding to
  Button-2 in 8.0. 
  -- 10/30/1999 hobbs


tkt_uuid: 1105738fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 9 Immediate
foundin: obsolete: 8.4.9
resolution: Fixed
title: segfault if tk_messageBox's parent is button
comment:
  Hi.

  I posted this bug at
  http://bugs.activestate.com/show_bug.cgi?id=36125
  first, and was adviced to refile on this site.

  I noticed following script crashed. This is illegual usage,
  but still should not be segfaulted.

  ////////////////////////////
  // script

  pack [button .b]
  tk_messageBox -parent ".b"

  ////////////////////////////
  // stack trace

  Function: TkWinGetIcon
          00247f5a 8b4d08 mov ecx,[ebp+0x8]
  ss:00d895ee=????????
          00247f5d 8b5114 mov edx,[ecx+0x14]
  ds:00d89e96=????????
          00247f60 52 push edx
          00247f61 e821f8ffff call Tk_GetHWND (00247787)
          00247f66 83c404 add esp,0x4
          00247f69 50 push eax
          00247f6a e82b010000 call TkWinGetIcon+0x1aa
  (0024809a)
          00247f6f 83c404 add esp,0x4
          00247f72 8945f4 mov [ebp+0xf4],eax
  ss:00d895ee=????????
          00247f75 8b45f4 mov eax,[ebp+0xf4]
  ss:00d895ee=????????
  Fault ->00247f78 8b88c4000000 mov ecx,[eax+0xc4]
  ds:000000c4=????????
          00247f7e 894df0 mov [ebp+0xf0],ecx
  ss:00d895ee=????????
          00247f81 8b55f0 mov edx,[ebp+0xf0]
  ss:00d895ee=????????
          00247f84 83baf000000000 cmp dword ptr
  [edx+0xf0],0x0 ds:00a0d1f1=6120726f
          00247f8b 7418 jz TkWinGetSystemPalette+0xad0
  (00250aa5)
          00247f8d 8b450c mov eax,[ebp+0xc]
  ss:00d895ee=????????
          00247f90 50 push eax
          00247f91 8b4df0 mov ecx,[ebp+0xf0]
  ss:00d895ee=????????
          00247f94 8b91f0000000 mov edx,[ecx+0xf0]
  ds:001300a0=00000000
          00247f9a 52 push edx
          00247f9b e84a000000 call TkWinGetIcon+0xfa
  (00247fea)
          00247fa0 83c408 add esp,0x8

  *----> Stack back trace <----*

  FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function
  0012F708 0023B8EA 00A4E280 00000000 00000003 00000000
  !TkWinGetIcon
  0012F914 10011D36 008EB640 008B4048 00000003 0012FB28
  !Tk_MessageBoxObjCmd
  0012F958 10012811 008B4048 00000003 0012FB28 00A4E131
  !TclEvalObjvInternal
  0012FB7C 10060FF0 008B4048 00A4E120 0000002C 00000000
  !Tcl_EvalEx
  0012FCC0 100600A5 008B4048 00959B58 0012FCE0 00959B58
  !Tcl_FSEvalFile
  0012FCD8 002ACD65 008B4048 008E3870 00000000 0030D078
  !Tcl_EvalFile
  0012FDF8 004010AB 00000001 008B2624 004010B9 008B4048
  !Tk_MainEx
  0012FF24 004015B9 00400000 00000000 00133346 00000001
  !<nosymbols>
  0012FFC0 77E7893D 00000000 00000000 7FFDF000 C0000005
  !<nosymbols>
  0012FFF0 00000000 00401485 00000000 000000C8 00000100
  kernel32!ProcessIdToSessionId 


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

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

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


tkt_uuid: 1078817fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 02. Appearance
priority: 5 Medium
foundin: None
resolution: None
title: Widget borders colourable
comment:
  Hi, I am a skin developer for Amsn, and I was just
  wondering if you have any plans to make borders of
  widgets colourable - ie for widgets with "solid" relief
  one could have a light blue face and dark blue border..
  this would make making Amsn even prettier a lot easier
  :) As a black border is not always desirable.

  Thanks,
  Tom


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

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


tkt_uuid: 220056ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.3b2
resolution: Duplicate
title: Wrong index returned by "dump" text widget sub-command in case of non-ascii characters
comment:
  OriginalBugID: 4043 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-19'
  LastModified: '2000-01-19'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2582
  OS: Linux
  OSVersion: Linux (also observed under Windows)
  Machine: PC/x86
  ClosedDate: '2000-01-19'


  Name: Claude Barras

  ReproducibleScript:
  wish 8.3
  % set t [text .t]; pack $t
  % $t insert insert "d\xE9j\xE0 loin"
  % $t dump 1.8

  ObservedBehavior:
  Result:
     text n 1.10
  instead of:
    text n 1.8
  (each non-ascii char is counted twice in the index)
  This seems to occur for any Tk version 8.1-8.3b2 and does have a severe
  impact in a real application for non-english text edition.
  It did work correctly with Tk 8.0.


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

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

        if {$data(-multiple)} {

  to:

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

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


tkt_uuid: 534755ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: Invalid
title: compound queries via canvas find
comment:
  Please consider enhancing the canvas find subcommand 
  (as well as the addtag subcommand) to allow compound 
  searches.

  something like ".c find withtag SOME_TAG && 
  overlapping $x1 $y1 $x2 $y2 && below OTHER_TAG"

  would make it easier than 3 separate searches
  and then doing some wired list operations to get
  the same effect - for completeness, sytax should
  allow grouping and negation

  No patch at this point - just wishfull thinking,
  when I have some free time I might look into this 
  myself.


tkt_uuid: 220329ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 2
foundin: obsolete: 8.3.1
resolution: Fixed
title: main application window does not come to foreground if action editor is open (XML Processor)
comment:
  OriginalBugID: 4745 Bug
  Version: 2.0b3
  SubmitDate: '2000-03-30'
  LastModified: '2000-05-17'
  Severity: MED
  Status: Released
  Submitter: key
  ChangedBy: angie
  RelatedBugIDs: 4017
  OS: All Unix
  ClosedDate: '2000-05-17'


  steps to reproduce:
  1)  start author
  2)  open project with XML Processor
  3)  open editor for XML Processor
  4)  move XML processor over the main application window (the one with the menu bar and tool bar)
  5)  click on the title bar of the main application window

  expected result:
  the main application window comes to foreground

  actual result:
  the main application window doesn't come to foreground.

  note:
  the main application window also doesn't come to the foreground when you switch to author "task"



  This is the standard behavior for transient windows. We can only fix this if we add the (already requested) Tk "wm style" command that allows us to be more specific as to which features we want to enable/diable for the window title.  
  -- 03/30/2000 sven
  Closed as bug.  RFE is in 4017. 
  -- 04/07/2000 hobbs
  setting this to duplicate so can track this for connect as well as tk 
  -- 04/12/2000 key


tkt_uuid: 1025471fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 52. [clipboard]
priority: 5 Medium
foundin: obsolete: 8.5a1
resolution: Invalid
title: Problem with newline translation when appending to clipboard
comment:
  To illustrate the problem perform the following command
  in a wish shell on Windows

  clipboard append -format STRING --
  "\"hello\nworld\"\ngoodbye\tworld"

  and then do a paste in cell A1 of an Excel document. At
  this point the first \n has produce a line break
  between "hello" and "world" in cell A1, the second \n
  caused insertion to move to cell A2 and the \t caused
  insertion to move to cell B2. Unfortunately there is an
  extra character after "hello" and before the line
  return in cell A1. I believe this is the result of
  blanket newline translation in the tkWinClipboard.c
  code. I don't think this issue is a "bug", but since
  there isn't any work-a-round I think an option should
  be added to the clipboard append command that would
  allow newline translation to be turned off. The
  translation needs to be truned off because the newline
  translations isn't uniform over the entire clipboard
  string but is based on context (i.e. is it within
  quotes or not).

  Tom Krehbiel
  tom.krehbiel@freescale.com


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

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


tkt_uuid: 220235ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 1 Zero
foundin: final: 8.1.1
resolution: Invalid
title: Tk bombs on canvImg.test
comment:
  OriginalBugID: 2727 Bug
  Version: 8.1.1
  SubmitDate: '1999-09-10'
  LastModified: '1999-09-20'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  ClosedDate: '1999-09-20'


  Name:
  Olivier Lefevre

  ReproducibleScript:
  I configured tcl and tk with './configure --enable-threads
      --enable-shared'  (plus
      --with-x for tk) and used gcc 2.95. Then 'make' and 'make test'

  ObservedBehavior:
  The test suite bombed with
      
      *** Error code 138



  Tcl is thread-safe, but Tk is not guaranteed to be so.  For 8.2.0,
  it is likely to work on Windows, and it is a pot-shot for Unix
  variants (depends on Xlib and X server used).  Further work is
  being done on this. 
  -- 09/20/1999 hobbs


tkt_uuid: 559435ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.4a5
resolution: None
title: tkUnixFont.c:Tk_DrawChars i18n problem
comment:
  As of 23 May 2002 cvs head, there is a problem with
  non-latin1 characters in Tk_DrawChars (unix). If the
  last character in the string is non-latin1, the entire
  last segment of line (having the same subfont) is not
  displayed at all. If I correct Tk_DrawChars assumption
  of 1byte=1char, I get the following: last character is
  displayed as "?" if it needs different subfont than
  previous character. Patch solving _both_ problems is 
  attached to this report.


tkt_uuid: 2878941fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Invalid
title: Tcl_ExternalToUtf(...dst, dstLen,...) writes to dst[dstLen]
comment:
  The docs of Tcl_ExternalToUtf() are unclear on the
  boundaries of the write buffer.  They say "... and up
  to dstLen converted bytes are  stored  in  dst." which
  suggests bytes will be written in dst[0] up 
  to dst[dstLen-1].  And that appears to be an accurate
  description of what the underlying ToUtfProc() does.
  However, then Tcl_ExternalToUtf() appends a terminating
  NUL character, and if the ToUtfProc has used all dstLen
  bytes, T_ETU writes to dst[dstLen].


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

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

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

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


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

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

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


tkt_uuid: 1010941fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.4.7
resolution: Fixed
title: panedwindow -sashwidth > -handlesize glitch
comment:
  If a panedwindow -sashwidth is greater than -
  handlesize, the handle is drawn in a strange location 
  (offset to the left).


tkt_uuid: 220424ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Compile Tk with Cygwin B20.1
comment:
  OriginalBugID: 1139 RFE
  Version: 8.0.4
  SubmitDate: '1999-02-02'
  LastModified: '1999-12-22'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  FixedDate: '1999-12-22'
  FixedInVersion: 8.3b1


  Name:
  Jan Nijtmans

  DesiredBehavior:
  Here are a number of trivial changes to Tk, which make Tk
  compilable with CygWin B20.1. All of those involve portability
  problems which don't show up with Borland and VC++, but they
  show up very clearly with gcc and egcs.
  - egcs and borland don't have the "zmouse.h" header file. This
    is very easy to escape, by puting in the definition of
    WM_MOUSEWHEEL directly.
  - The function GetCurrentTime() is obsolete, and replaced by
    GetTickCount(). egcs only supports the newer function.
  - TkFontAttributes is defined both in tkFont.h and tkWinInt.h
    cygwin complains about that.
  - in tkFont.c, stricmp() is used in stead of strcasecmp().
    Cygwin only supports strcasecmp()
  - The definition of Status conflicts with some cygwin headers
    changing this to a typedef solves this problem.



  Patch:
  *** win/tkWinX.c.origSat Oct 10 02:30:37 1998
  --- win/tkWinX.cWed Jan 27 08:17:44 1999
  ***************
  *** 20,26 ****
     * The zmouse.h file includes the definition for WM_MOUSEWHEEL.
     */
    
  ! #include <zmouse.h>
    
    /*
     * Definitions of extern variables supplied by this file.
  --- 20,26 ----
     * The zmouse.h file includes the definition for WM_MOUSEWHEEL.
     */
    
  ! #define WM_MOUSEWHEEL (WM_MOUSELAST+1)
    
    /*
     * Definitions of extern variables supplied by this file.
  ***************
  *** 1057,1061 ****
    unsigned long
    TkpGetMS()
    {
  !     return GetCurrentTime();
    }
  --- 1057,1061 ----
    unsigned long
    TkpGetMS()
    {
  !     return GetTickCount();
    }
  *** win/tkWinInt.h.origMon Sep 14 20:24:00 1998
  --- win/tkWinInt.hWed Jan 27 08:17:43 1999
  ***************
  *** 36,42 ****
    #define WS_EX_TOOLWINDOW0x00000080L 
    #endif
    
  ! typedef struct TkFontAttributes TkFontAttributes;
    
    /*
     * The TkWinDCState is used to save the state of a device context
  --- 36,42 ----
    #define WS_EX_TOOLWINDOW0x00000080L 
    #endif
    
  ! /*typedef struct TkFontAttributes TkFontAttributes;*/
    
    /*
     * The TkWinDCState is used to save the state of a device context
  *** win/tkWinFont.c.origWed Jan 27 10:54:47 1999
  --- win/tkWinFont.cWed Jan 27 10:55:24 1999
  ***************
  *** 179,192 ****
         * Windows likes.
         */
    
  !     if ((stricmp(lf.lfFaceName, "Times") == 0)
  !     || (stricmp(lf.lfFaceName, "New York") == 0)) {
    strcpy(lf.lfFaceName, "Times New Roman");
  !     } else if ((stricmp(lf.lfFaceName, "Courier") == 0)
  !     || (stricmp(lf.lfFaceName, "Monaco") == 0)) {
    strcpy(lf.lfFaceName, "Courier New");
  !     } else if ((stricmp(lf.lfFaceName, "Helvetica") == 0)
  !     || (stricmp(lf.lfFaceName, "Geneva") == 0)) {
    strcpy(lf.lfFaceName, "Arial");
        }
    
  --- 179,192 ----
         * Windows likes.
         */
    
  !     if ((strcasecmp(lf.lfFaceName, "Times") == 0)
  !     || (strcasecmp(lf.lfFaceName, "New York") == 0)) {
    strcpy(lf.lfFaceName, "Times New Roman");
  !     } else if ((strcasecmp(lf.lfFaceName, "Courier") == 0)
  !     || (strcasecmp(lf.lfFaceName, "Monaco") == 0)) {
    strcpy(lf.lfFaceName, "Courier New");
  !     } else if ((strcasecmp(lf.lfFaceName, "Helvetica") == 0)
  !     || (strcasecmp(lf.lfFaceName, "Geneva") == 0)) {
    strcpy(lf.lfFaceName, "Arial");
        }
    
  *** xlib/X11/Xlib.h.origWed Apr  1 12:03:08 1998
  --- xlib/X11/Xlib.hWed Jan 27 08:49:21 1999
  ***************
  *** 58,64 ****
  --- 58,70 ----
    typedef char *XPointer;
    
    #define Bool int
  + /* The Status define conflicts with some Cygwin headers.  So on
  +    Windows we use a typedef instead.  */
  + #if defined(__WIN32__) || defined(_WIN32)
  + typedef int Status;
  + #else
    #define Status int
  + #endif
    #define True 1
    #define False 0
    




  PatchFiles:
  tkWinX.c tkWinInt.h tkWinFont.c Xlib.h




  These are all handled in 8.3b1 except for zmouse, which we
  still expect to be included. 
  -- 12/22/1999 hobbs


tkt_uuid: 220594ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: Pointer smash in TkpDisplayButton
comment:
  OriginalBugID: 2733 Bug
  Version: 8.0.5
  SubmitDate: '1999-09-10'
  LastModified: '1999-09-15'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0 SP5
  Machine: X86
  FixedDate: '1999-09-15'
  FixedInVersion: 8.2.1


  Name:

  Kevin Kenny



  CVS:

  * RCS: @(#) $Id: tkWinButton.c,v 1.2 1998/09/14 18:23:59 stanton Exp $



  Extensions:

  Many homegrown extensions.



  CustomShell:

  Running against an unmodified core



  Comments:

  This bug is present against all releases of Tk since 7.6.  The 8.2

      general

      release does NOT fix it.

      

      A possible alternative to invoking TkpDisplayButton directly

      from ButtonProc might be to let the idle loop do the display.

      The code would look like:

      

      if ( ! ( butPtr->info.flags & REDRAW_PENDING ) ) {

          butPtr->info.flags |= REDRAW_PENDING;

          Tcl_DoWhenIdle( TkpDisplayButton, (ClientData) butPtr );

      }

      

      I'm not really confident, though, of how this might interact

      with the rest of the event processing on Windows.



  ReproducibleScript:

  # This problem is horribly difficult to reproduce; I've reconstructed

      # it from a post-mortem dump.  There is a timing problem on Windows if

      # a button is destroyed at exactly the wrong point during its creation.



  ObservedBehavior:

  The sequence of events, as I reconstruct it, is:

      

      - The button is created, and windowed into a text widget.

      - The button is scheduled for redraw.  The REDRAW_PENDING bit is set,

        and TkpDisplayButton is scheduled with Tcl_DoWhenIdle

      - A WM_PAINT event arrives, causing TkpDisplayButton to run from the

        ButtonProc function in tkWinButton.c.  REDRAW_PENDING is cleared

        from the button's instance data.

      - Another background event handler causes the button to be destroyed.

        DestroyButton doesn't see REDRAW_PENDING, and so doesn't cancel the

        Tcl_DoWhenIdle call.

      - Eventually, Tcl_ServiceIdle calls TkpDisplayButton.  The client data

        is a dangling pointer to the destroyed button's instance data.

      Results

        are unpredicatable, but unlikely to be amusing.



  DesiredBehavior:

  Clearly, Tk shouldn't crash!



  Patch:

  *** tkWinButton.c Tue Feb 23 23:22:00 1999

  --- tkWinButton.c.proposed Thu Sep  9 13:08:02 1999

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

  *** 783,788 ****

  --- 783,796 ----

        BeginPaint(hwnd, &ps);

        EndPaint(hwnd, &ps);

        TkpDisplayButton((ClientData)butPtr);

  + 

  +     /*

  +      * Special note: must cancel any existing idle handler

  +      * for TkpDisplayButton;  it's no longer needed, and

  +      * TkpDisplayButton cleared the REDRAW_PENDING flag.

  +      */

  +     

  +     Tcl_CancelIdleCall( TkpDisplayButton, (ClientData) butPtr );

        return 0;

    }

    case BN_CLICKED: {



  PatchFiles:

  tkWinButton.c





  Fixed in 8.3b1. 
  -- 09/15/1999 hobbs


tkt_uuid: 734498ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Fixed
title: canvas postscript command core dumps on special polygon
comment:
  Hi,

  there is a bug in tkCanvPoly.c:PolygonToPostscript in 
  recent Tk Versions (tested 8.3.5, 8.4.2).


  Create a polygon with two identical points and no
  outline color (I know this seems to be nonsense,
  but in my case it was absolutely needed).
  Do a postscript command on the canvas and you get the
  core dump (a color
  NULL pointer is passed on from PolygonToPostscript to
  Tk_PostscriptColor, where it is referenced)


  15:09[wilm@rubin:ConStruct3]$ wish
  .wishrc .wishrc .wishrc ...
  % canvas .c
  .c
  % pack .c
  % .c create polygon 10 20 10 20
  1
  % .c postscript
  Segmentation fault




  Setting the outline sets the color pointer to non-NULL:

  15:41[wilm@rubin:ConStruct3]$  wish
  .wishrc .wishrc .wishrc ...
  %  canvas .c
  .c
  % pack .c
  % .c create polygon 10 20 10 20 -outline black
  1
  % .c postscript
  %!PS-Adobe-3.0 EPSF-3.0
  ...



  To avoid this create a polygon with 3 points (using two
  different points
  activates expansion to three points and cirumvents the
  faulty if-clause as well):

  16:04[wilm@rubin:ConStruct3]$ wish
  .wishrc .wishrc .wishrc ...
  % canvas .c
  .c
  % pack .c
  % .c create polygon 10 20 10 20 10 20 
  1
  % .c postscript
  %!PS-Adobe-3.0 EPSF-3.0
  ...



  To patch this just check if color==NULL in case
  polyPtr->numPoints==2 and return TCL_OK
  See attachment.

  Andreas Wilm


tkt_uuid: 1676673fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: new test failures
comment:
  On Solaris 9 /CDE, these
  test failures are new since
  8.5a5. Failures happen
  in both --enable- and --disable-xft
  configurations:

  ==== panedwindow-29.1 resizing width FAILED
  ==== Contents of test case:
  panedwindow .p -bd 5
          frame .f1 -width 100 -height 50 -bg blue
          frame .f2 -width 100 -height 50 -bg red

          .p add .f1 -sticky news
          .p add .f2 -sticky news
          pack .p -side top -fill both -expand 1
          wm geometry . ""
          update
          # Note the width
          set a [winfo width .f2]
          # Increase the size by 10
          regexp {^(\d+)x(\d+)} [wm geometry .] -> w h
          wm geometry . [expr {$w + 10}]x$h
          update
          set b "$a [winfo width .f2]"
  ---- Result was:
  178 188
  ---- Result should have been (exact matching):
  100 110
  ==== panedwindow-29.1 FAILED



  ==== panedwindow-29.2 resizing height FAILED
  ==== Contents of test case:
  panedwindow .p -orient vertical -bd 5
          frame .f1 -width 50 -height 100 -bg blue
          frame .f2 -width 50 -height 100 -bg red

          .p add .f1 -sticky news
          .p add .f2 -sticky news
          pack .p -side top -fill both -expand 1
          wm geometry . ""
          update
          # Note the height
          set a [winfo height .f2]
          # Increase the size by 10
          regexp {^(\d+)x(\d+)} [wm geometry .] -> w h
          wm geometry . ${w}x[expr {$h + 10}]
          update
          set b "$a [winfo height .f2]"
  ---- Result was:
  128 138
  ---- Result should have been (exact matching):
  100 110
  ==== panedwindow-29.2 FAILED


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: 220181ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.1b3
resolution: Invalid
title: Exit Window
comment:
  OriginalBugID: 1921 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-22'
  LastModified: '1999-08-08'
  Severity: SER
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows 95
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-08'


  Name:  Chang LI
  email:  changl@neatware.com
  Support:  None
  Severity:  2
  OperatingSystem:  Windows 95
  Synopsis:  Exit Window

  ReproducibleScript:
      Click the exit button on the title bar of Tk Window cause system error.
      It just exit the entire process. Suppose we have a main process, and it
      open a Tk window, when this Tk window exit, we require it only destroy
      its own window. But current Tk implementation kill the main process
      either.
      And you have to keep a Tk window in active. You can not destroy it. 
      This is not the case of Tk8.0. 
      
      The thread code of Tk8.1b3 may cause this clearnup problem althought I
      did
      not enable the thread. 
      

  ObservedBehavior:
      When you run wish81 there is another Tk window. When you click the exit
      button
      on the title bar of the Tk window, you should not kill the wish81
      console
      window itself. 
      

  Patch:
  Maybe you can use the DeleteWindowsExitProc(NULL) replaces the ExitProcess.
  Posted To comp.lang.tcl: Posted Successfully



  The behavior observed is correct.  Kiiling the '.' (main) toplevel
  window is synonymous with exit in wish in the main interpreter.
  If the user wants to catch this, they need:
    wm protocol . WM_DELETE_WINDOW <SaveMeProc> 
  -- 08/08/1999 hobbs


tkt_uuid: 2886436fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 4
foundin: obsolete: 8.5.7
resolution: None
title: [.txt delete] still deletes before startindex
comment:
  Consider following code:
  pack [text .t]
  .t insert end foo\nbar
  .t delete 2.0 end

  This should only delete the second line ("bar"), and leave "foo\n" in the text. However, it actually deletes the newline too, leaving only "foo". This is wrong, since [.t delete 2.0 end] should *never* delete anything before index 2.0 !

  I'm here proposing the same patch as in tracker 1854913. That one was closed with a different solution, fixing only the symptoms in interactive mode (<Delete> key deleting backwards), but not the cause.

  Apparently, the proposed patch broke 'text-19.8' of the tk testsuite. In my opininion, that test is wrong. It deletes from index 4.0, and then checks that the selection tag ends at index 3.5. But it should still include the newline at the end of line 3. (Without this patch, that newline did not exist anymore!)

  I've attached a file which includes the original solution for 1854913, and a patch for test-19.8.


tkt_uuid: 220762ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 2
foundin: obsolete: 8.4a1
resolution: Fixed
title: Tk_GetHWND is not exported through the tk stub table
comment:
  OriginalBugID: 6183 Bug
  Version: 8.4a1
  SubmitDate: '2000-08-30'
  LastModified: '2000-09-06'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All Windows
  FixedDate: '2000-09-06'
  FixedInVersion: 8.4a2


  Name:
  George Petasis

  ReproducibleScript:
  Tk_GetHWND is not exported through the tk stub table, so
  it is not possible to build a stubs enabled extension that uses
  this function under windows...

  DesiredBehavior:
  Tk_GetHWND must be exported through the tk stub table



  Tk_GetHWND is exported, but the file tkPlatDecls.h was not being included in tk.h, nor was it being installed with the public header files.  Thus, it was not accessible from a vanilla Tcl/Tk installation.  I added 
  '#include "tkPlatDecls.h"' to tk.h, and added tkPlatDecls.h to the list of header files to install.  This should correct the problem.  This fix will be in 8.4a2.

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

  -- 09/05/2000 ericm

  It turns out that including tkPlatDecls.h in tk.h causes some build problems:  first, tkPlatDecls.h must #include windows.h, to get definitions for things like HWND.  But this also brings in all the other windows decl's, some of which conflict with internal, private Tk functions (oops).  So instead, developers will have to #include "tkPlatDecls.h" themselves, as needed.  tkPlatDecls.h will still be installed, so that developers can do this include.

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

  -- 09/06/2000 ericm


tkt_uuid: 220881ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: obsolete: 8.3b2
resolution: None
title: font create does not recognises national fonts properly (was OK in
comment:
  OriginalBugID: 3552 Bug
  Version: 1.3
  SubmitDate: '1999-11-11'
  LastModified: '2000-05-18'
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: NT 4.0 Hebrew Enabled
  Machine: Pentium 2 350 MHz 128 Mb ram


  Name:
  Yaniv Kimchi

  Comments:
  I will send as well the needed fonts in a compresses file.

  ReproducibleScript:
  In use Windows98/NT which is Hebrew Enabled. 
  Hebrew is written right to left and Windows has got a terrible algorithm to support Hebrew editing and display. The appearance of teh text on the screen depends if the font is dfined as BIDI (generic MS win hebrw) or regular.
  To avoid this issue I use a Web designed Heberw font which for the system behaves like and English font.
  In TCLpro 1.2 This was OK.
  the code :
  set hebrewfont {Web Hebrew AD}
  set hebfont [font create -family $hebrewfont -size 11]

  Created the needed font handle and texts on the screen appeared the way I wanted them to.
  HOWEVER in TclPro1.3 it seems this font is NOT loaded. and all my screens mess right to left and back.
  I had to downgrade back to TCLPRO1.2 to continue developement although I need badly some features evailable only in 1.3 (like Thread control).

  ObservedBehavior:
  All texts reverse now left to right.

  DesiredBehavior:
  The way it was in TCLPRO1.2



  Please send the fonts that show the problem. 
  -- 05/18/2000 hobbs


tkt_uuid: 220300ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 1 Zero
foundin: obsolete: 8.3.1
resolution: Invalid
title: Test suite failures may indicate serious series of problems in latest patched Tk
comment:
  OriginalBugID: 5399 Bug
  Version: 8.3.1
  SubmitDate: '2000-05-09'
  LastModified: '2000-06-02'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: Solaris 2.6
  Machine: Ultra 5
  ClosedDate: '2000-06-02'


  Name:
  Larry W. Virden

  CVS:
  May 9, 2000, 10:16 am EDT

  Extensions:
  Tk

  CustomShell:
  Mirrored the CVS for tcl and tk.

  Comments:
  I'm using Solaris 2.6's CDE environment.

  ReproducibleScript:
  make test
  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:  117539
    Current serial number in output stream:  117542

  At this point, the test suite hangs...

  make: *** [test] Error 1
  ~

  DesiredBehavior:
  all test cases pass



  I cannot repeat these on our Solaris8 CDE environment. 
  -- 06/02/2000 hobbs


tkt_uuid: 220589ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: Highlight color & highlight background inverted for canvas
comment:
  OriginalBugID: 2674 Bug
  Version: 8.2
  SubmitDate: '1999-08-31'
  LastModified: '1999-09-01'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 7
  Machine: Other
  FixedDate: '1999-09-01'
  FixedInVersion: 8.2.1


  Name:

  Colin McDonald



  ReproducibleScript:

  pack [canvas .c -highlightcolor red] -fill both

      focus .c



  ObservedBehavior:

  The red highlight color is displayed when the canvas widget does not

      have focus,

      and not when it has focus.



  DesiredBehavior:

  Display the highlight color when the widget has focus.



  Patch:

  *** tkCanvas.c.origFri Aug 20 09:38:37 1999

  --- tkCanvas.cFri Aug 20 09:41:54 1999

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

  *** 1842,1851 ****

        GC fgGC, bgGC;

        

                 

  !     bgGC = Tk_GCForColor(canvasPtr->highlightColorPtr,

        Tk_WindowId(tkwin));

        if (canvasPtr->textInfo.gotFocus) {

  ! fgGC = Tk_GCForColor(canvasPtr->highlightBgColorPtr,

    Tk_WindowId(tkwin));

        TkpDrawHighlightBorder(tkwin, fgGC, bgGC, canvasPtr->highlightWidth,

            Tk_WindowId(tkwin));

  --- 1842,1851 ----

        GC fgGC, bgGC;

        

                 

  !     bgGC = Tk_GCForColor(canvasPtr->highlightBgColorPtr,

        Tk_WindowId(tkwin));

        if (canvasPtr->textInfo.gotFocus) {

  ! fgGC = Tk_GCForColor(canvasPtr->highlightColorPtr,

    Tk_WindowId(tkwin));

        TkpDrawHighlightBorder(tkwin, fgGC, bgGC, canvasPtr->highlightWidth,

            Tk_WindowId(tkwin));



  PatchFiles:

  tkCanvas.c


tkt_uuid: 739833ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: Fixed
title: if S variable is set, mkLinks fails
comment:
  If S variable is set, mkLinks fails to cross link
  man-pages.

  Fix: Add following line to top of mkLinks script:

  S=""

  This problem is valid for both tcl and tk 8.4.2


tkt_uuid: 2975142fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: tk::CheckEnter broken with itcl variables
comment:
  # Tk 8.5.8 with Itcl on Linux (does not happen in 8.5.5).
  # Error when a *itcl* variable is used as -variable for checkbutton.
  # tk::CheckEnter assumes it can access the variable in global scope by prefixing it with "::"
  # This is wrong for variables in itcl-namespaces:

  wm geometry {.} 100x100
  package require Itcl

  itcl::class testclass {
      private variable foobar 1
      constructor {} {
  pack [checkbutton .c -indicatoron false -variable [itcl::scope foobar]] -fill x
      }
  }

  testclass #auto

  # Move mouse over checkbutton:
  # can't read "::@itcl ::testclass0 ::testclass::foobar": no such variable
  # can't read "::@itcl ::testclass0 ::testclass::foobar": no such variable
  #     while executing
  # "set ::[$w cget -variable]"
  #     (procedure "tk::CheckEnter" line 26)
  #     invoked from within
  # "tk::CheckEnter .c"
  #     (command bound to event)

  # proposed patch: use uplevel instead of ::, see attached patch


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

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


tkt_uuid: 3572695fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.6b3
resolution: None
title: Tk-Cocoa crashes on copy operation in text widget
comment:
  Make a text widget in a fresh Wish 8.6b3 in Tk-Cocoa on a Mac (I used OS X 10.8.2 here):

  text .t
  pack .t

  Then do the following:
  1. type some text into the text widget
  2. mark some text and do either cm+c to copy it or cmd+x to cut it out

  Tk will then crash with the following info:

  0   Tk                            0x000cbb6d TkpMakeWindow + 271
  1   Tk                            0x0003a27b Tk_MakeWindowExist + 135
  2   Tk                            0x0001515d TkClipInit + 152
  3   Tk                            0x00014f8e Tk_ClipboardClear + 54
  4   Tk                            0x000159f0 0x8000 + 55792
  5   Tcl                           0x0014c4f0 TclNREvalObjv + 2256
  6   Tcl                           0x001a1cc3 0x13d000 + 412867
  7   Tcl                           0x00149753 TclNRRunCallbacks + 70
  8   Tcl                           0x0014cde0 0x13d000 + 64992
  9   Tcl                           0x0014d266 Tcl_EvalEx + 58
  10  Tk                            0x0001300c Tk_BindEvent + 3740
  11  Tk                            0x00018a65 TkBindEventProc + 306
  12  Tk                            0x0001e0b5 Tk_HandleEvent + 1448
  13  Tk                            0x0001daab 0x8000 + 88747
  14  Tcl                           0x001d5b82 Tcl_ServiceEvent + 268
  15  Tcl                           0x001d5c6e Tcl_ServiceAll + 186
  16  Tcl                           0x002240a6 0x13d000 + 946342
  17  com.apple.CoreFoundation      0x970f1dfe __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30
  18  com.apple.CoreFoundation      0x970f1d3d __CFRunLoopDoObservers + 381
  19  com.apple.CoreFoundation      0x970cbecf __CFRunLoopRun + 1071
  20  com.apple.CoreFoundation      0x970cb63a CFRunLoopRunSpecific + 378
  21  com.apple.CoreFoundation      0x970cb4ab CFRunLoopRunInMode + 123
  22  com.apple.AppKit              0x93935edc _NSUnhighlightCarbonMenu + 185
  23  com.apple.AppKit              0x93ceae7f -[NSCarbonMenuImpl performMenuAction:withTarget:] + 378
  24  com.apple.AppKit              0x93c62f1b -[NSMenu _performKeyEquivalentWithDelegate:] + 389
  25  com.apple.AppKit              0x93c62fd6 -[NSMenu _performKeyEquivalentWithDelegate:] + 576
  26  com.apple.AppKit              0x93c62abb -[NSMenu performKeyEquivalent:] + 72
  27  com.apple.AppKit              0x93c61f5c -[NSApplication _handleKeyEquivalent:] + 915
  28  com.apple.AppKit              0x93b17ee1 -[NSApplication sendEvent:] + 5512
  29  Tk                            0x000d7823 0x8000 + 849955
  30  Tk                            0x000d7bab 0x8000 + 850859
  31  Tcl                           0x001d5d70 Tcl_DoOneEvent + 180
  32  Tk                            0x0001d89c Tk_MainLoop + 36
  33  Tk                            0x0002bbd2 Tk_MainEx + 1470
  34  wish-aqua8.6                  0x0000453e 0x1000 + 13630
  35  wish-aqua8.6                  0x000044cd 0x1000 + 13517


  Also, when pasting text from other sources into the text widget, nothing happens and the pasted text does not occur in the widget.


tkt_uuid: 3567838fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.6b3
resolution: None
title: unixMenu.test noise
comment:
  With --enable-aqua build on Snow Leopard all
  tests in unixMenu.test pass.  However, a lot of
  noisy lines get spilled onto the console like this:

  Fri Sep 14 20:53:44 Donald-Porters-MacBook-Pro.local tktest[56070] <Error>: kCGErrorIllegalArgument: CGSClearWindowTags: Invalid window 0x0

  Seems something not right is going on somewhere.


tkt_uuid: 1446343fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 61. Safe Tk
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: None
title: text/entry widget in safe interpreter
comment:
  The following problem occured with tk8.4.13rc0 as well
  as with tk8.4.12, but ONLY when running under Windows
  (WinXP SP1):
  When creating a text or entry widget in a safe
  interpreter it is not possible to enter text in these
  widgets (not even an input cursor when selecting the
  widget).
  I used the following script to demonstrate the bug:
      set engine [safe::interpCreate]
      safe::loadTk $engine
      $engine eval {
         pack [entry .e] [text .t] [button .b -text "OK"
  -command {.t insert end "OK "}]
      }


tkt_uuid: 220937ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Invalid
title: Access Violation
comment:
  OriginalBugID: 6027 Bug
  Version: 8.3
  SubmitDate: '2000-07-19'
  LastModified: '2000-07-19'
  Severity: CRIT
  Status: UnAssn
  Submitter: shawn
  ChangedBy: shawn
  OS: Windows 2000


  Also winNT

  To Reproduce: 

  Run the code in /home/bugs/tcltk/6027/tktest.tcl 

  Work in a directory structure with *.test files in it - below lib. 

  It takes a minute to load or so - If there are no test files listed you can open one from the file menu > open. 

  If there are - double click on a test file from the list to load it in to the window above -

  Select the top of the file down to the end of the first test - 

  Select run from the buttons at the top right of the app - with the idea being to execute the selected code. 

  Wish blows chunks - 

  I don't know if this is also true in unix - or just specific to windows. 
  m
  I think it blows out when it tries to source tcltest for the second time - so I am thinking that it is important to select the setup stuff from the file.  But not positive. 


tkt_uuid: 583293ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: Duplicate
title: Test file listbox.test - failure
comment:
  Compiled with SUN's cc
  Running on SunOS with Reflection-X as X-emulator
  Test report:
  listbox.test

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

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

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


tkt_uuid: 1642750fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 55. [focus]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: focus-5.1 test suite case fails ni 8.5a6
comment:
  Tk cvs head, as retrieved from Activestate's cvs ftp site
  Sun C compiler, compiled on SPARC Solaris 9  with options \"'--prefix=/projects/sprs_lwv/tcl85' '--enable-shared' '--enable-symbols' '--enable-stubs' '--enable-64bit' 'CC=cc'\"

  Tk test suite run on SPARC Solaris 9, displaying to two platforms: Sun's solaris 9 x server and exceed running on windows xp

  Yes, I ran the test suite twice, comparing the two servers, because of the errors I was seeing in the test suite.

  In both cases, I'm seeing the same error:

  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 (exact matching):
  .t {} {}
  ==== focus-5.1 FAILED


tkt_uuid: 3416492fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 9 Immediate
severity: Minor
foundin: obsolete: 8.5.10
resolution: Fixed
title: Crash in open/save file dialog in Windows 7 libraries
comment:
  Open (and presumably Save) file dialogs crash in Windows 7 when attempting to open a file located in a Library (e.g. Documents, Pictures, Videos, Music). Opening the same file through its actual path works fine (i.e., clicking on Libraries, then Documents, then whatever.txt, then Open will crash; actually clicking through the folders C:\Users\bob\Documents, clicking whatever.txt, and clicking Open will work fine). I haven't actually run the code through a debugger to verify 100%, but I believe this is a bug in OFNHookProcA/W in tkWinDialog.c. Since Libraries are collections of folders, they're not represented by one single path, so calling SendMessage() with CDM_GETFOLDERPATH fails (returns < 0) when the user navigates to a Library in the dialog; this would cause the buffer size in OFNHookProc to be calculated incorrectly, which is what I believe is causing the crash.

  I noticed this bug when trying to use tkinter.filedialog.askopenfilename() in Python 3.2.2 (Python 3.2 actually uses Tk 8.5.9, but the problematic SendMessage() code appears to be unchanged in 8.5.10, so I've filed this under the current version). I've attached a zip file containing a Python script to replicate the bug and C++ code to demonstrate how CDM_GETFOLDERPATH fails inside Libraries. Note that the dialog won't crash if you go into a folder inside a Library, as once you're inside that folder, there's a real, logical path for CDM_GETFOLDERPATH to return; it only fails if you select a file immediately inside the Library itself.


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: 949477ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Duplicate
title: tk on aqua doesn't know when iconified
comment:
  1. start wish
  2. click on the "-" bubble and the window is iconified to the dock
  3. type "wm state ." to the shell
  4. the answer is "normal" when it should be "iconified"


tkt_uuid: 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: 3405839fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 7 High
foundin: obsolete: 8.6b2
resolution: Fixed
title: Writing PNG images sometimes generates wrong sBIT chunk
comment:
  When writing PNG images, the sBIT chunk is always written with a length of 4. This should actually vary depending on the color type.

  Script to reproduce the problem:
  image create photo foo -width 20 -height 20
  foo write foo.png -format png

  This writes a PNG file with color type 4, which should have an sBIT chunk of 2 bytes.


tkt_uuid: 220159ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Invalid
title: wish (and tktest) core dumps
comment:
  OriginalBugID: 1731 Bug
  Version: 8.1b2
  SubmitDate: '1999-04-05'
  LastModified: 
  Severity: CRIT
  Status: Closed
  Submitter: pat
  RelatedBugIDs: 1748
  OS: Digital Unix
  Machine: Other
  ClosedDate: '1999-04-07'


  Name:
  James Hemmerle

  CustomShell:
  I have changed the core files listed above so that wish will work on my machine (by putting an & in front of the key values).  However, those changes might not work on operating systems with data sizes that return 1 for the calls to the Tcl_InitHashTable given above.

  ReproducibleScript:
  entry .e

  ObservedBehavior:
  wish core dumps (or exits with a panic) on a number of the test scripts.
      This occurs when widgtes are created and are getting configured.

      This seems to be related to the hash tables created in the three files 
      1. tkBitmap.c (in BitmapInit() -
      Tcl_InitHashTable(&dispPtr->bitmapIdTable, sizeof(Pixmap) 
                      /sizeof(int)))
      2. tkCursor.c (in CursorInit() -
      Tcl_InitHashTable(&dispPtr->cursorIdTable, sizeof(Display *) 
          /sizeof(int)))
      3. tkGC.c (in GCInit() -
      Tcl_InitHashTable(&dispPtr->gcIdTable, sizeof(GC)/sizeof(int));

      In all three cases, the second argument to the Tcl_InitHashTable has a
      value of 2.  When these tables are later used in the code, the key value
      given to functions are not integer arrays.
      For example, in the GetCursor function in TkCursor.c ther is a line
          cursorPtr->idHashPtr = Tcl_CreateHashEntry(&dispPtr->cursorIdTable, 
                  (char *) cursorPtr->cursor, &new);
      This function calls CreateArray which tries to read elements of an array
      pointed to by (char *)cursorPtr->cursor but that is not a legal memory
      location.

      4. I also get an exception in the tests in scale.test.  This has to do
         with the value of the variable "value" not being intialized in
         the function ConfigureScale() in tkScale.c.  The command in the test
         that causes the problem is ".s configure -variable x".  Since x
      doesn't
         exist the variable "value" is used but not initialized causing an
         exception in a call to floor().



  parts 1-3 are not reporducable--probable unique to the custom interp.
  part 4 is logged as a seperate bug:  1748
  -hershey


tkt_uuid: 1288433fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.4.11
resolution: None
title: LisboxSelect event triggers when listbox state is disabled
comment:
  This code

     pack [listbox .l] 
     .l insert end 1 2 3 
     bind .l <<ListboxSelect>> {puts click!} 
     .l configure -state disabled

  shows that the ListBoxSelect event will be triggered regardless of the state 
  of the listbox. Although the listbox is "disabled" so no selection can be 
  made, the event fires, indicating a selection has been made.

  Jeff Hobbs writes on this subject:

  (http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/
  b63e43a981b6a698/93341e895ba0c054)

  "Hmm, I would cal that a low priority bug.  It appears that the 
  ListboxSelect is merely triggering unnecessarily.  The items 
  are not actually being selected, so functionally it is all OK, 
  but we could avoid the ListboxSelect, so we should."

  A workaround on script level is to check for the listbox state in the code for 
  the binding:

  bind .l <<ListboxSelect>> {
     # abort, if disabled: 
     if {[%W cget -state]=="disabled"} {break} 
     # else do the normal action:
     # ...
  }


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: 220402ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: send crashes and dde probs under Win98
comment:
  OriginalBugID: 891 Bug
  Version: 8.1a2
  SubmitDate: '1998-12-03'
  LastModified: '1999-03-31'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: redman
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-03-31'
  FixedInVersion: NA


  Name:  Roland De Bie
  email:  rol@myself.com
  Support:  None
  Severity:  1
  OperatingSystem:  Windows 98
  OperatingSystemVersion:  4.10.1998
  CustomShell:  None!

  I use two running Wish81 and try to communicate with each other, using only command lines in the console.

  Synopsis:  send crashes and dde probs under Win98

  ObservedBehavior:
  send, whatever are the arguments, always crash the master TclTk program

  dde execute send the command string but append garbage (missing 0 byte at the end of string?)

  dde request correctly gets the variable from the host, but again the variable's content is trashed.

  DesiredBehavior:
  No more garbage characters, no more crashes!



  03/31/1999 15:47 - redman - Fixed, DDE doesn't give the correct data length on Win95/98.


tkt_uuid: 220550ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: System stops with coredump while inserting lines in a text-widget
comment:
  OriginalBugID: 2316 Bug
  Version: 8.1.1
  SubmitDate: '1999-07-01'
  LastModified: '1999-12-16'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 1265 2044 2261 2716
  OS: AIX
  OSVersion: AIX 4.3.2
  Machine: RS6000
  FixedDate: '1999-12-16'
  FixedInVersion: 8.3b1


  Name:
  Siegfried Weigl

  Comments:
  This bug was also reported for version tk8.0.4

  ReproducibleScript:
  1. Start Interpreter 'wish'
      2. Type following text:
      % text .t
      .t
      % pack .t
      % .t insert end "Hello world"
      % Segmentation fault(coredump)



  AIX has an outstanding reoccuring problem with the text widget.
  It works for some, but in some magic compiler/version combo
  there seems to be an error.  This might be related to the fact
  that AIX is the only Unix we know that cores on ckalloc(0).
  This must be examined further (it must work for some AIX users,
  otherwise we'd expect more mail...)
  -- 08/20/1999 hobbs
  This turns out to be a bug in the IBM compiler (not noted for
  being the best).  The fix is to remove -O (optimization) from
  the CFLAGS.  This will be the default for 8.3, and we are
  also going to try and get the gcc options working properly. 
  -- 12/16/1999 hobbs


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: 220515ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: 100% CPU Usage on some system commands.
comment:
  OriginalBugID: 1959 Bug
  Version: 8.1.1
  SubmitDate: '1999-04-29'
  LastModified: '1999-08-09'
  Severity: CRIT
  Status: Released
  Submitter: surles
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-09'
  FixedInVersion: 8.2b2


  04/29/1999 10:16 - surles -
  I can make the CPU usage jump to 100% by calling some system commands.  In a previous bug report, the user thrashed the CPU by calling an invalid system command (something like command.com / r foo)  We assumed it was a bug in the OS due to the fact that the call was bad.

  However, using Tcl8.1.1 version of prowish81d.exe on WinNT sp3, I can thrash the CPU by calling the "mem" system command from WISH ONLY!!!  In Tclsh this command returns perfectly.  Could this be a Console bug???

  NOTE: Looking at the Task Manager, the prowish process is not thrashing the CPU.  The executable that is going nuts is ntvdm.exe.



  Fixed in 8.2b2, or is it? 
  -- 08/09/1999 redman


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: 503772ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Fixed
title: Nonblinking cursor in TW after disabling
comment:
  Hi,

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


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

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

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

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

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

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

  Alexander Buzin

  #beginning of example

  set widget_status normal

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

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

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

  wm deiconify .
  focus .t1

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

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

  #end of example


tkt_uuid: 220090ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.4a1
resolution: Duplicate
title: Program coredumps with 8.1, 8.2, 8.3 and 8.4a1
comment:
  OriginalBugID: 5955 Bug
  Version: 8.4a1
  SubmitDate: '2000-06-27'
  LastModified: '2000-07-20'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 5960
  OS: Linux-Red Hat
  OSVersion: redhat 6.2
  Machine: i686
  FixedDate: '2000-07-20'


  Name:
  Lindsay Marshall

  Extensions:
  none

  ReproducibleScript:
  I am manipulating a canvas widget that is representing a tree on-screen. I have some window items that have an entry in them. When the user types the correct thing in the entry the entry is replaced with a text string, the window items
  are deleted and some subnodes are drawn. If you enter an incorrect value and then correct it, the failure does not happen. I am working on a cut down script, but the program though fairly small is realtively complex....

  ObservedBehavior:
  wish gives a segmentation fault.

  DesiredBehavior:
  No segmentation fault!


tkt_uuid: 2912799fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.6b1.1
resolution: Invalid
title: Compilation breaks on win7 with vs2008
comment:
  If I try to compile the latest csv branch tk stopf compilation with this error

  *** Linker has 'Win98 alignment problem'
  *** Intermediate directory will be '.\Release_VC9\tk_Dynamic'
  *** Output directory will be '.\Release_VC9'
  *** Suffix for binaries will be ''
  *** Optional defines are '-DTCL_CFGVAL_ENCODING=\"cp1252\" -DSTDC_HEADERS -DTCL_
  CFG_OPTIMIZED'
  *** Compiler version 9. Target machine is IX86
  *** Compiler options '-W3  -Ot -Oi -fp:strict -Gs -GS -GL  -RTC1 -W3'
  *** Link options '-ltcg'
  *** Dependency rules are not being used.

  NMAKE : fatal error U1073: don't know how to make 'htmlhelp'

  This is fixed if I modify the line 58.
  Not that the patch below modifies two more lines for my system configuration.

  In C:\Users\Lis\Documents\work\tcl-cvs\tk\win: "C:\Program Files (x86)\CVSNT\cvs.exe" -q diff -u -r 1.7 
  buildall.vc.bat
  CVSROOT=:pserver:anonymous@tktoolkit.cvs.sourceforge.net:/cvsroot/tktoolkit

  Empty password used - try 'cvs login' with a real password
  Index: buildall.vc.bat
  ===================================================================
  RCS file: /cvsroot/tktoolkit/tk/win/buildall.vc.bat,v
  retrieving revision 1.7
  diff -u -r1.7 buildall.vc.bat
  --- buildall.vc.bat   2 Oct 2008 19:13:35 -0000   1.7
  +++ buildall.vc.bat   11 Dec 2009 17:20:15 -0000
  @@ -30,9 +30,10 @@
   :: might not be correct.  You may need to edit these.
   ::
   if not defined MSDevDir (
  -    call "C:\Program Files\Microsoft Developer Studio\vc98\bin\vcvars32.bat"
  +    ::call "C:\Program Files\Microsoft Developer Studio\vc98\bin\vcvars32.bat"
       ::call "C:\Program Files\Microsoft Developer Studio\vc\bin\vcvars32.bat"
       ::call c:\dev\devstudio60\vc98\bin\vcvars32.bat
  +    call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\vcvars32.bat"
       if errorlevel 1 goto no_vcvars
   )
   
  @@ -47,7 +48,7 @@
   :: just to be explicit and convey understanding to the user.  Setting
   :: the INSTALLDIR envar prior to running this batchfile affects all builds.
   ::
  -if "%INSTALLDIR%" == "" set INSTALLDIR=C:\Program Files\Tcl
  +if "%INSTALLDIR%" == "" set INSTALLDIR=C:\tcl
   
   
   :: Where is the Tcl source directory?
  @@ -58,7 +59,8 @@
   ::
   set OPTS=none
   if not %SYMBOLS%.==. set OPTS=symbols
  -nmake -nologo -f makefile.vc release htmlhelp OPTS=%OPTS% %1
  +::nmake -nologo -f makefile.vc release htmlhelp OPTS=%OPTS% %1
  +nmake -nologo -f makefile.vc release OPTS=%OPTS% %1
   if errorlevel 1 goto error
   
   :: Build the static core, dlls and shell.


tkt_uuid: 220282ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 33. Generic Dialog Support
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: BWidget Dialog does not appear when . is withdrawn
comment:
  OriginalBugID: 4221 Bug
  Version: 8.3
  SubmitDate: '2000-02-22'
  LastModified: '2000-04-19'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4266 4997 3597
  OS: Windows NT
  ClosedDate: '2000-04-19'


  Name:
  Carsten Lund

  Extensions:
  BWidget-1.2.1

  CustomShell:
  Both Tk and BWidgets are clean.

  Comments:
  If you deiconify . afterward the dialog appears.
      
      Debuging the problem a little it dialog is waiting in a "tkwait
      visibility .p"
      
      Looking through the BugDB is seems that it may have something to do with
      TR#3597
      I had the same problem using Window98, but not under unix.

  ReproducibleScript:
  package require BWidget
  wm withdraw .
  PasswdDlg  .p

  ObservedBehavior:
  The password dialog never appears

  DesiredBehavior:
  The password dialog appears.



  8.3 corrected the behavior of transients in Tk to correctly
  follow the style for MS Windows transients - if the parent is
  not shown, the child should not be shown.  This requires more
  correct coding for the users (it is no longer acceptable to
  expect a transient of a withdrawn window to be visible).

  We've made some changes for some base dialogs in Tk to
  account for this as well. 
  -- 04/19/2000 hobbs


tkt_uuid: 2879930fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: Wont Fix
title: Disabled menu items do not get highlighted in torn-off menus
comment:
  Standard Windows behaviour is to highlight a menu item when a mouse moves over it, whether the item is enabled or not. The real menus do so, but when the menu with disabled items is torn-off, these disabled items are not highlighted on mouse move.


tkt_uuid: 220216ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Invalid
title: Tk_ItemType and OLD_CONFIG
comment:
  OriginalBugID: 2423 Bug
  Version: 8.1
  SubmitDate: '1999-07-20'
  LastModified: '2000-02-07'
  Severity: SER
  Status: Closed
  Submitter: jenn
  ChangedBy: hobbs
  OS: Linux
  OSVersion: Red Hat 5.0+ on Intel
  ClosedDate: '2000-02-07'


  Name:  Spiros Boucouris

  CustomShell:  No changes to core.  Locally compiled
  source release from Scriptics.


  ObservedBehavior:
      
      In tk.h, Tk_ItemType is conditionaly compiled under #ifndef
      __NO_OLD_CONFIG
      
      I cannot find anything that looks like a replacement.  The code that
      handles
      the configuration of Tk_Item(s) is marked as deprecated.  There are
      subtle
      differences to the behaviour of the custom item configuration that
      require changes on our code.  We cannot make these until the fate of
      custom Tk_Item(s)
      has been cleared.
      

  DesiredBehavior:
      
      It appears that 8.1 moved to the new Tk_Option for widgets and orphaned
      the
      canvas items.  We depend on custom canvas items, so we would like to see
      a consistent (old or new does not matter so much) API.  The present
      release looks like it was changed by someone who had no idea that canvas
      items existed
      (not very reassuring).
      

  Comments:
      
      Even the built-in canvas items now call the "deprecated, included only
      for backward compatibility" routines for handling configureSpec(s).
      Please ensure that side effects of changes are dealt with, especially in
      final releases.
      


  The user needs to elaborate more specifically on what they were
  attempting, what they wanted, and how it didn't work.  There are
  several extensions that create custom canvas item types in Tk 8.1+
  (BLT and Snack most notably), using a well-documented mechanism. 
  -- 02/07/2000 hobbs


tkt_uuid: 3607787fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 69. Events
priority: 7 High
foundin: None
resolution: None
title: Expand [event info] to show which event(s) have a keysym
comment:
  Right now, there's no way to tell (short of looping over all event names) which events are bound to a keysym. To get "Select All" behaviour for Control-a, I have

    event add <<SelectAll>> <Control-a> <Control-A>

  in my app. What I didn't realise (as I develop on Windows) is that, on Linux, these keysyms are already added to <<LineStart>>. When someone reported that Control-a wasn't doing 'Select All', we had to guess and poke around to find what was happening. It would be helpful if

  event info <Control-a>

  which is currently invalid and returns an error would, instead, return a list of all events which have the keysym added.


tkt_uuid: 220459ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: Tk hangs if compiled with --enable-threads
comment:
  OriginalBugID: 1527 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-18'
  LastModified: '1999-03-26'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: surles
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  FixedDate: '1999-04-15'
  FixedInVersion: 8.1


  Name:
  Petasis Georgios

  ReproducibleScript:
      If you compile both tcl and tk with --enable-threads, wish just hangs
      after
      a while. Also, although I have download tk8.1b2, the directory created
      after unataring was named tk8.1b2, tk_patchLevel reports 8.1b1!
      (There is NO other version installed on machine). This happens under 
      Solaris 2.6.
      




  4/15/99 - redman - the patch level problem was a known bug in b2, fixed in b3.  I've already fixed two problems in Tk regarding hanging, one was for the Notifier locking itself up which is probably the case for this bug.  There is not enough information to figure this out for sure, though.


tkt_uuid: 541849ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 9 Immediate
foundin: obsolete: 8.4a4
resolution: Fixed
title: error with -overrelief & disabled widget
comment:
  If I create a widget with a -overrelief and an 
  initially disabled state, there is an error when the 
  mouse leaves the widget.

  The following reproduces the problem on my win2k box:

  button .b -text "Hello" -state disabled -overrelief 
  raised -relief flat
  pack .b

  run the above, and move the cursor over and then away 
  from the button. I get the following error:


  Error: can't read "Priv(relief)": no such element in 
  array

  Looking in button.tcl, the problem is in the procedure 
  tk::ButtonEnter or tk::ButtonLeave. Take your pick :-)

  Notice that in tk::ButtonEnter, Priv(relief) is only 
  set if the widget is *not* disabled. However, a 
  similar check for disabled-ness isn't made in 
  tk::ButtonLeave. 

  The bug has other cool side effects as well. 
  Ferinstance, run the following:


  button .b1 -state normal -overrelief sunken -relief 
  flat -text b1
  button .b2 -state disabled -overrelief raised -relief 
  groove -text b2
  pack .b1 .b2

  Move your mouse over b1 and then b2. Notice that when 
  you move the mouse away from b2 it gets the relief of 
  b1. This is because Priv(relief) is set when the mouse 
  enters b1, and isn't reset when the mouse leaves. When 
  the mouse enters b2, Priv(relief) is not set, so on 
  <Leave> the widget gets whatever relief was in play 
  for the last enabled button widget. 

  Bummer, huh?

  One fix might be simply to move all of the code in 
  ButtonLeave inside a check on the state. It seems to 
  work on my box for the above two test cases.

  proc ::tk::ButtonLeave w {
      variable ::tk::Priv
      if {[string compare [$w cget -state] "disabled"]} {
  $w configure -state normal

         # Restore the original button relief if the 
  mouse button is down
         # or there is an -overrelief value.

         if {[string equal $Priv(buttonWindow) $w] || \
                 [string compare [$w cget -
  overrelief] ""] } {
            $w configure -relief $Priv(relief)
         }
      }

      set Priv(window) ""
  }

  I've attached a patch that moves the code under the 
  test for disabledness. I also took the liberty of 
  converting those brain-numbing [string compare]'s with 
  the new "eq" and "ne" operators, and attempted to make 
  appropriate changes in the unix and mac 
  implementations, but have no way to test them. So 
  tread cautiously with the patch...


tkt_uuid: 222014ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Duplicate
title: bgerror doesn't skip messages with break
comment:
  OS: Windows, Linux

  According to the documentation:

  "If several background errors accumulate before bgerror is invoked to process them, bgerror will be invoked once for each error, in the order they occurred. However, if bgerror returns with a break exception, then any remaining errors are skipped without calling bgerror."

  In the 8.0 version, "return -code break" works as expected.

  In the 8.3.2 version, the "return -code break" command in the bgerror handlers causes an exception and messages continue to be displayed.

  To reproduce:

  launch wish8.3.2

  button .b -text "Button" -command foobar
  pack .b

  proc bgerror {error} {

     return -code break
  }

  Then click on the button. Notice the message in the standard output:

  bgerror failed to handle background error.
      Original error: invalid command name "foobar"
      Error in bgerror: invoked "break" outside of a loop


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

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

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


tkt_uuid: 220133ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 1 Zero
foundin: obsolete: 8.0p2
resolution: Invalid
title: WinNT: buttons have too much padding
comment:
  OriginalBugID: 1394 Bug
  Version: 8.0p2
  SubmitDate: '1999-03-02'
  LastModified: '1999-08-07'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows NT
  Machine: X86
  ClosedDate: '1999-08-07'


  Name:
  John Wiersba

  ReproducibleScript:
  button .b -pady 0 -text high
  pack .b

  ObservedBehavior:
  on WinNT (version 8.0 according to $tcl_patchLevel), when I set -pady to 0, the button still has a lot of padding above/below the text.

  DesiredBehavior:
  no padding at all when -pady is set to 0



  The user needs to make use of -ipadx/-ipday as well. 
  -- 08/07/1999 hobbs


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

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

  Example code:

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


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

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

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

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

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

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

  Francois


tkt_uuid: 220557ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: Tk_MeasureChars inconsistency causes text display problems
comment:
  OriginalBugID: 2362 Bug
  Version: 8.1.1
  SubmitDate: '1999-07-16'
  LastModified: '1999-12-16'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 98
  Machine: X86
  FixedDate: '1999-12-16'
  FixedInVersion: 8.3b1


  Name:
  Frederic BONNET

  Comments:
  Workaround: use strictly negative maxPixels values when measuring
      unbounded text lines (eg. -1 instead of 0).  The new behavior is
      platform-consistent.

  ObservedBehavior:
  According to the Tk_MeasureChars man page:
      
      " If maxPixels is greater than 0, it specifies the longest permissible
      line length in pixels.  Characters from string are processed only until
      this many pixels have been covered.  If maxPixels is <= 0, then the line
      length is unbounded and the flags argument is ignored. "
      
      This was true in Tk8.0.5 and prior versions but isn't in Tk8.1.1:
      maxPixels must be < 0 (and not <=) for the line length to be unbounded.
      This is an undocumented potential incompatibility.

  DesiredBehavior:
  Either revert to the old behavior (for better backward compatibility) or
      update the man page and the change log.



  It was decided that 0 should be an allowed length that shouldn't
  mean all (this makes it more consistent with other areas of Tcl/Tk),
  and the docs were unfortunately not updated.  This has been fixed
  for 8.3b1. 
  -- 12/16/1999 hobbs


tkt_uuid: 220863ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.2
resolution: Fixed
title: tkConfig.sh generated is incomplete
comment:
  OriginalBugID: 2668 Bug
  Version: 8.2
  SubmitDate: '1999-08-31'
  LastModified: '2000-03-02'
  Severity: CRIT
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  Machine: Other


  Name:
  Larry W. Virden

  CVS:
  Aug. 27, 1999, 8am

  Extensions:
  tcl/tk/tclx

  CustomShell:
  none

  ReproducibleScript:
  $ $PWD/configure  --prefix=/usr/tcl82 --exec-prefix=/usr/tcl82/sun4
      --with-cc=cc --with-x --x-includes=/usr/openwin/include
      --x-libraries=/usr/openwin/lib --enable-shared
      
      $ make all test install

  ObservedBehavior:
  $ grep L /usr/tcl82/sun4/lib/tkConfig.sh
      TK_PATCH_LEVEL='.0'
      TK_DEFS=' -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DSTDC_HEADERS=1
      -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_PW_GECOS=1 '
      TK_SHARED_BUILD=
      TK_LIB_FILE='libtk8.2.so'
      TK_LIBS='-L/usr/openwin/lib -lX11 -ldl  -lsocket -lnsl -lm'
      TK_XINCLUDES='-I/usr/openwin/include'
      # Linker switch(es) to use to link with the X11 library archive.
      TK_XLIBSW='-L/usr/openwin/lib -lX11'
      TK_LIB_FLAG='-ltk8.2'
      TK_BUILD_LIB_SPEC='-L/vol/tclsrcsol/tcl82/tk8.2.0/unix -ltk8.2'
      TK_LIB_SPEC='-L/usr/tcl82/sun4/lib -ltk8.2'
      # Location of the top-level source directory from which Tk was built.
      TK_CC_SEARCH_FLAGS='-Wl,-R,${LIB_RUNTIME_DIR}:/usr/openwin/lib'
      TK_LD_SEARCH_FLAGS='-R ${LIB_RUNTIME_DIR}:/usr/openwin/lib'
      TK_STUB_LIB_FILE='libtkstub8.2.a'
      TK_STUB_LIB_FLAG='-ltkstub8.2'
      TK_BUILD_STUB_LIB_SPEC='-L/vol/tclsrcsol/tcl82/tk8.2.0/unix -ltkstub8.2'
      TK_STUB_LIB_SPEC='-L/usr/tcl82/sun4/lib -ltkstub8.2'
      TK_BUILD_STUB_LIB_PATH='/vol/tclsrcsol/tcl82/tk8.2.0/unix/libtkstub8.2.a'
      
      TK_STUB_LIB_PATH='/usr/tcl82/sun4/lib/libtkstub8.2.a'
      
      Notice in the above that several of the variables are missing the -R
      flag.
      When these flags are used, the resulting binary are not able to locate
      the dynamic libraries without users having to modify their environments
      which is not possible at times (due to conflicts between requirements).
      
      Also, I've encountered problems with the -Wl,-R, notation - Sun's
      compiler tends to generate an error when this is used.
      
      Here is an example of the error:
      
      /usr/ccs/bin/ld -G -z text -Wl,-R,/usr/tcl82/sun4/lib/:/usr/openwin/lib
      -R /usr/tcl82/sun4/lib  ...
      
      (where I've deleted the remainder of the statement due to size.)
      
      /usr/ccs/bin/ld: illegal option -- W
      /usr/ccs/bin/ld: illegal option -- W
      usage: ld [-abd:e:f:h:il:mo:rstu:z:B:D:F:GI:L:M:N:Q:R:S:VY:] file(s)
              [-a]            create an absolute file
      
      Also, I am uncertain that the variable should be in there - if it is
      null,
      there is likely to be other errors.
      
      I also notice similar errors in the tclConfig.sh - along with this
      peculiar
      occurance:
      
      /usr/tcl82/sun4/lib/tclConfig.sh:
      # Default linker flags used in an optimized and debuggable build,
      respectively.
      TCL_LDFLAGS_DEBUG='@LDFLAGS_DEBUG@'
      TCL_LDFLAGS_OPTIMIZE='@LDFLAGS_OPTIMIZE@'
      
      The tclx from the Scriptics CVS repository shows a similar peculiarity:
      
      /usr/tcl82/sun4/lib/tclxConfig.sh:
      #
      # Search flags that specify how to find the TclX shared libraries at run
      time
      # on some systems.
      #
      TCLX_LD_SEARCH_FLAGS='@TCLX_LD_SEARCH_FLAGS@'
      
      These @something@  strings should have values substituted.

  DesiredBehavior:
  I would expect to see -R flags used on systems where they
      are available (perhaps with a configure flag in the case of
      users who don't want them for whatever reason).  I would
      expect to see @something@ strings replaced with text.  And
      I would hope that flags generated in files were usable everywhere.


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

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


tkt_uuid: 3184834fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: None
title: xft detection script should directly link with freetype
comment:
  The xft detection script should directly link with the freetype, otherwise the xft is not detected on systems with disabled indirect linking (e.g. Fedora). This bug originates from: https://bugzilla.redhat.com/show_bug.cgi?id=677692


tkt_uuid: 2543460fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.5.6
resolution: None
title: Enter/Leave cnv events not reported while mouse btn is down
comment:
  consider this little testcase:

  pack [canvas .c -width 300 -height 190 -background white]
  # two test items
  .c create rectangle 20 30 40 50 -tags red -fill red
  .c create rectangle 80 30 100 50 -tags black -fill black
  # text items for showing what's happening
  .c create text 20 90 -text {red: } -tags txt1 -anchor nw
  .c create text 20 120 -text {tags: } -tags txt2 -anchor nw
  # bind <Enter> and <Leave>
  .c bind red <Enter> {.c itemconfigure txt1 -text red:\ Enter}
  .c bind red <Leave> {.c itemconfigure txt1 -text red:\ Leave}
  # the workaround: (this fails too)
  bind .c <Motion> {.c itemconfigure txt2 -text tags:\ [.c gettags [.c find withtag current]]}
  # not really needed for this testcase:
  bind .c <ButtonPress> {.c configure -background red}
  bind .c <ButtonRelease> {.c configure -background white}


  item with 'red' tag is bound to <Enter> and <Leave> events.
  but it works only when the bouse button are not pressed.
  if you click in the white area and drag over the red item, it won't send the <Enter>/<Leave> events.

  in addition, an attempt to workaround this issue by using [.canvas find withtag current&&$myTag] would fail too, because tag 'current' is not updated while mouse button is down.

  I don't know if this is expected, or not.
  reading the manual of canvas I'd expect 'current' tag and <Enter>/<Leave> events to work in any condition.

  I'm not filing a bug about documentation though.
  I'd rather want those things working (perhaps enabled by some exotic [canvas] option), because a full workaround on this issue implies various nested loops, to track position and retrieve all the tags,  and match them, and other than awful, I think it could turn into a performance hog.

  Best regards


tkt_uuid: 2945130fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: {Shift,Control,Alt}_R press is answered by _L release
comment:
  Pressing the right Shift, Control, or Alt key on Windows (checked only with Tk 8.5.7) produces
  correctly an event with a ..._R keysym. However releasing the
  same key produces an event with a ..._L keysym. The same works as
  expected on X11 systems.

  The bug was originally reported for Perl/Tk. See
  https://rt.cpan.org/Ticket/Display.html?id=47173

  For your convenience, a test script is attached.

  Regards,
      Slaven


tkt_uuid: 220572ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: scrollbar configure options don't
comment:
  OriginalBugID: 2491 Bug
  Version: 8.0.5
  SubmitDate: '1999-08-03'
  LastModified: '1999-08-04'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  Machine: X86
  FixedDate: '1999-08-04'
  FixedInVersion: 8.2


  Name:
  Bob Halpin

  CustomShell:
  none

  Comments:
  Win NT 4.0 (SR5)

  ReproducibleScript:
  scrollbar .s
      pack .s -expand true -fill y
      .s configure -troughcolor red

  ObservedBehavior:
  Troughcolor doesn't change. In fact, most -configure options don't work.

  DesiredBehavior:
  troughcolor change to blue (and other options work as well.)



  Certain options are not enabled for Tk widgets that are actually
  wrappers around native widgets (like the scrollbar), because
  that is not allowed on that platform.  This is essentially a
  doc bug since it wasn't clarified (but now is). 
  -- 08/04/1999 hobbs


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: 3102228fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: <<ListboxSelect>> Doesn't fire when selection lost
comment:
  Assuming that the selection state of a listbox reflects the physical state of a system, then <<ListboxSelect>> should fire whenever the selection state of the listbox changes. This happens for mouse clicks in the listbox, but not when the listbox loses the selection. Consider the following script. If one or more entries in the listbox are selected, then clicking "take" removes the selection (the entries are no longer highlighted). However, the bound "puts" doesn't fire to indicate this change in state.

  listbox .l
  .l insert 0 1 2 3
  pack .l
  button .b -text "take" -command {selection own .b}
  pack .b
  bind .l <<ListboxSelect>> {puts [selection get]}


tkt_uuid: 3107485fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: None
title: ttk::treeview heading height calculation bug
comment:
  Setting multiline text headings in the ttk::treeview widget shows a wrong calculation in heading height. This effect appears after the first time a treeview widget is destroyed. Any newly created treeview will have a heading height corresponding to a single line text.

  Demo script:

  package require Tk

  proc buildtree {tv} {
      catch {destroy $tv}
      ttk::treeview $tv -columns {hello bye} -show headings
      $tv column hello -width 120 -stretch 0
      $tv column bye   -width 120 -stretch 0
      $tv heading hello -text "Hello\n$tv"
      $tv heading bye   -text "Bye\n$tv"
      # this ought to work
      $tv heading #0 -text "H\nj"
      pack $tv
  }

  buildtree .tv1
  buildtree .tv2
  after 3000 buildtree .tv1


tkt_uuid: 220758ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: obsolete: 8.4a1
resolution: Fixed
title: Add a '-state' flag to the listbox
comment:
  OriginalBugID: 6052 RFE
  Version: 8.4a1
  SubmitDate: '2000-07-25'
  LastModified: '2000-07-28'
  Severity: MED
  Status: Released
  Submitter: kuchler
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-07-28'
  FixedInVersion: 8.4a2


  We should add a -state option to the listbox to make it more consistant
  with labels, buttons, entries, etc.

  For a listbox this would mean that selection wouldn't be drawn and the
  foreground color for entries in the listbox would be 'disabled foreground'
  colored.

  I am not sure if there is anything additional that needs to happen in
  disabled state for a listbox.



  I added a -state option to the listbox.  It grays the widget, does not draw selection, and does not draw item specified fore/background colors.  In addition, like a disabled entry, you cannot edit the contents or change the selection values or anchor.  Essentially, "modify" behaviors are turned off.

  This is documented in the manual entry, and there are tests for the new state.

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

  -- 07/28/2000 ericm


tkt_uuid: 220519ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.1
resolution: Fixed
title: tk_popup fails when called too quickly
comment:
  OriginalBugID: 2009 Bug
  Version: 8.1
  SubmitDate: '1999-05-07'
  LastModified: '1999-05-07'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  OS: HP-UX
  OSVersion: 10.20
  Machine: Other
  FixedDate: '1999-05-07'
  FixedInVersion: 8.1.1


  Name:

  Frank J. Leitner



  Comments:

  This error happens in all 8.x version i've tried so far. The second part

      of

      the patch fixes a bug reported by John Chambers on compl.lang.tcl on

      Tue, 04 May 1999 (Message-ID: <372EED34.DD6FC493@gte.com>).



  ReproducibleScript:

  Simple popup menu:

      

        menu .m

        .m add command -label "whatever"

        bind . <Button-1> {tk_popup .m %X %Y}

      

      And now multi-click on the toplevel widget at a high frequency. After

      some

      tries, the following error message appears:



  ObservedBehavior:

  grab failed: window not viewable

          while executing

      "grab -global $menu"

          (procedure "tkMenuButtonDown" line 33)

          invoked from within

      "tkMenuButtonDown .m

      "

          (command bound to event)



  DesiredBehavior:

  No error message:-)



  Patch:

  *** menu.tcl.orig       Fri May  7 14:05:36 1999

  --- menu.tcl    Fri May  7 14:20:28 1999

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

  *** 555,560 ****

  --- 555,565 ----

    proc tkMenuButtonDown menu {

        global tkPriv

        global tcl_platform

  + 

  +     if {![winfo viewable $menu]} {

  +         return

  +     }

  + 

        $menu postcascade active

        if {[string compare $tkPriv(postedMb) ""]} {

          grab -global $tkPriv(postedMb)

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

  *** 1242,1248 ****

          tkMenuUnpost {}

        }

        tkPostOverPoint $menu $x $y $entry

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

          tkSaveGrabInfo $menu

          grab -global $menu

          set tkPriv(popup) $menu

  --- 1247,1254 ----

          tkMenuUnpost {}

        }

        tkPostOverPoint $menu $x $y $entry

  !     if {![string compare $tcl_platform(platform) "unix"]

  !           && [winfo viewable $menu]} {

          tkSaveGrabInfo $menu

          grab -global $menu

          set tkPriv(popup) $menu



  PatchFiles:

  library/menu.tcl


tkt_uuid: 1033299fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: None
resolution: None
title: Add -class option to canvas
comment:
  Canvas widgets are very useful thing to use as base for
  megawidget construction. Given that canvas can contain
  embedded windows, it can be considered container widget
  just like frame and toplevel.

  But because there is no -class option, options database
  cannot be used do control behavoir of canvas-based
  megawidgets, without enclosing canvas into frame which
  sole purpose to provide class. This makes application
  widget tree overcomplicated and hamper use of Tk
  introspection features.

  Canvas widget has very few global option by itself, and
  they are seldom globally changed using option database.

  Even better is to allow certain groups of canvas items
  to have its own database class within parent canvas
  namespace.


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: 658197ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Out of Date
title: TkAqua: torn-off menus are not functional
comment:
  This is on MacOS X 10.2.x, with the latest Tk-cvs-head.

  Torn-off menus which should appear in a floating
  palette are first of all drawn completely in black
  (sometimes if you move the mouse over the items they
  are drawn correctly), and events don't seem to
  propagate correctly to the floating window.


tkt_uuid: 220061ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 1 Zero
foundin: obsolete: 8.3b2
resolution: Duplicate
title: Img support in Tk fails to display JPG file
comment:
  OriginalBugID: 4125 Bug
  Version: 8.3b2
  SubmitDate: '2000-02-04'
  LastModified: '2000-02-07'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  RelatedBugIDs: 4127
  OS: Windows NT
  OSVersion: Windows NT V4.0 SP3
  Machine: Gateway Pentium II 166Mhz
  ClosedDate: '2000-02-07'


  Name:
  David Burns

  Extensions:
  Proper behavior under wish82 w/"Img12.exe" installed.

  CustomShell:
  Unvarnished binary Tcl/Tk 8.3b2 downloaded 2/3/2000 from Scriptics site

  Comments:
  The following approach used to attempt to load the "image" widget won't
      work either under 8.3b2:

      set pixlen [file size "image.jpg"]
      open "image.jpg" ifile
      fconfigure $ifile -translation binary -encoding binary
      image create photo -data [read $ifile $pixlen] -format JPEG]

      This results in an empty image (no error message).

  ReproducibleScript:
  >From NT MS-DOS box, issue "wish83", at the % prompt, type "source canvas.tcl"
  where "canvas.tcl" is the following script:
  #======================================
  # "canvas.tcl" - Canvas/Image test

  global tk_version
  if {$tk_version == "8.2" } {
      package require Img
      }

  global Image_cds

    set fullfname "image.jpg"

    set Image_cds(ww) "."

    set image [image create photo -file $fullfname]

      set Image_cds(can) [canvas $Image_cds(ww).c  -borderwidth 0 -highlightthickness 0]
      pack $Image_cds(can) -side top

      # Create an 'image' canvas item to receive the actual image
      set Image_cds(ib) [$Image_cds(can) create image 0 0 -anchor nw]

      $Image_cds(can) itemconfigure $Image_cds(ib) -image $image
      set Image_cds(image) $image
  #=====================================end of script

  ObservedBehavior:
  When run under "wish82" with the "Img" package installed from "Img12.exe",
  the response is:

  image1
  %

  When run under Tcl/Tk 8.3b2, the response is:

  couldn't recognize data in image file "image.jpg"
  %

  DesiredBehavior:
  The proper behavior is that seen under "wish82"  (V8.2.0) with Img12.exe distributed Img extension installed.


tkt_uuid: 3574854fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: None
title: OSX/X11: font panic
comment:
  % font actual {zapfdingbats 12 roman normal} -family 
  X Error of failed request:  BadValue (integer parameter out of range for operation)
    Major opcode of failed request:  45 (X_OpenFont)
    Value in failed request:  0xc00005
    Serial number of failed request:  73
    Current serial number in output stream:  74

  Same thing works fine in 8.5 .  Some missing backport?

  Also test numbers in font.test have many dups.  Also fixed in 8.5.


tkt_uuid: 1233014fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.4.11
resolution: None
title: Alt / Command mismatch
comment:
  On OSX the reported keysym for pressing the command key is 
  either Alt_L or Alt_R. However, when using Alt as part of a [bind] 
  specification (f.ex. <Alt-q>), the callback never gets called. Only 
  Command-q will work.


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

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

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

  Notice that the bounding box is larger than the text.

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


tkt_uuid: 3500545fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.13
resolution: Fixed
title: tk_getOpenFile -multiple 1 wrong on windows
comment:
  on windows [tk_getOpenFile -multiple 1] returns wrong results, 
  when one or multiple file name, containing a path, are entered maunally.
  The resulting file names get the current path prepended, regardless
  wether they contain already a path or not.

  Since 8.5.9 the code in GetFileNameW() and  OFNHookProcW() do their own buffer/selection handling
  which is somehow buggy ;-(

  Here are the steps to reproduce the bug with tcl/tk 8.5.11 on windows:

  tk_getOpenFile -multiple 1 -initialdir c:/windows
  #(enter c:\autoexec.bat)
  -> C:/WINDOWS/c:/autoexec.bat


tkt_uuid: 3059100fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: Missing documentation for wm attributes -type
comment:
  X Window Extended Window Manager Hints were added
  as the wm attributes -type option in Tip 359
  This has not been documented in the wm man page.

  A list of possible values could be adapted from the
  _NET_WM_WINDOW_TYPE section of
  http://standards.freedesktop.org/wm-spec/wm-spec-latest.html


tkt_uuid: 830668ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Duplicate
title: umask 027 issue
comment:
  tk 8.3.4

  When umask is set to 027 during compilation (may be 022 during make install), the resulting /usr/bin/wish8.3 has incorrect privileges rwxr-x---

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


tkt_uuid: 2901053fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: iconified toplevel cannot be restored (Windows only)
comment:
  The attached example causes the following problem:

  1. Start: wish desktop.tcl
  2. Press Button "Dialog" -> Application modal toplevel appears
  3. Iconify all existing windows using the "Show Desktop"-Button right next to the Start-Button of the Taskbar
  4. Start another Application (eg. firefox)
  5. Try to restore the iconified TK-App using its icon in the taskbar -> nothing happens !!!!


  Workaround:
  The only way to restore the dialog is to push it to the foreground with the Windows Task Manager. 
  But this can mean that it is shown everytime another application is started. 

  Comment:
  The problems only occurs if the dialog is application-modal. The grab command 
  seems to cause the problem.The example has been taken 
  from the Iwidgets Shell Widget class and has beem changed so that it runs without 
  Itk, Itcl and Iwidgets. The implementation is very similar to the TCL script 
  implementation of the tk_messageBox dialog for Unix.


tkt_uuid: 1067251fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a1
resolution: None
title: test failure winWm
comment:
  in cvs head, this test fails:


  ==== winWm-5.1 UpdateGeometryInfo: menu resizing FAILED
  ==== Contents of test case:

      set result {}
      toplevel .t
      frame .t.f -width 150 -height 50 -bg red
      pack .t.f
      update
      set result [winfo height .t]
      menu .t.m
      .t.m add command -label foo
      .t conf -menu .t.m
      update
      lappend result [winfo height .t]
      .t.m add command -label "thisisreallylong"
      .t.m add command -label "thisisreallylong"
      update
      lappend result [winfo height .t]
      destroy .t
      set result

  ---- Result was:
  50 50 31
  ---- Result should have been (exact matching):
  50 50 50
  ==== winWm-5.1 FAILED


tkt_uuid: 220631ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: Missing global statement in "tkfbox.tcl"
comment:
  OriginalBugID: 3735 Bug
  Version: 8.2.2
  SubmitDate: '1999-12-01'
  LastModified: '1999-12-16'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  FixedDate: '1999-12-16'
  FixedInVersion: 8.3b1


  Name: George Petasis



  ReproducibleScript:

  in "tkfbox.tcl" around line 833 (tk runtime library):



  if {![info exists tkPriv(updirImage)]} {

  set tkPriv(updirImage) [image create bitmap -data........



  but tkPriv is not declared as a global variable in that procedure



  ObservedBehavior:

  You cannot change the bitmap used in the file selection dialog

  to a user defined one, as can be done with the icons used for

  folders and files... (and make the file dialog has the look n feel of

  the rest of the applicatio under unix...)





  fixed for 8.3b1. 
  -- 12/16/1999 hobbs


tkt_uuid: 1394260fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: Invalid
title: Mouse wheel doesn't modify for ScrolledWindow
comment:
  The mouse wheel works for moving a ScrolledWindow
  widget up and down, but so do ctrl-mousewheel and
  shift-mousewheel. One of these (probably
  shift-mousewheel) should scroll horizontally while the
  other should be left for the developer to do something
  application-specific, e.g., zoom.


tkt_uuid: 3382423fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: wm forget / manage crash and zombie windows
comment:
  I stumbled across an issue with wm forget/wm manage on Aqua. One of the symptoms also appears on Windows. 
  Issue 1:
  "wm forget" doesn't work correctly, when the toplevel has never been mapped so far:
  package require Tk
  toplevel .t
  # update
  wm forget .t

  WIthout the update, on Windows I get a "zombie" frame .t - it is possible to pack anythng inside, but it never updates. If it is undocked using wm manage, the toplevel doesn't repaint. WIth an "update" in between, it works on Windows. Only on X11, it works correctly. On Aqua, it crashes in Tk_WmDeadWindow. 

  Issue 2: On Aqua, repeatedly docking/undocking a frame irregularly crashes in Tk_WmDeadWIndow at "wm forget". Code:
  package require Tk
  toplevel .dock
  pack [ttk::label .dock.text -text "This is a toplevel\nwhich can be docked"]
  pack [ttk::button .dock.d -text "(un)dock" -command dock]
  pack [ttk::label .p -text "Place your \nwindow here"] -side left

  set docked false
  proc dock {} {
    if {$::docked} {
      pack forget .dock
      wm manage .dock
      set ::docked false
    } else {
      wm forget .dock
      pack .dock -side left
      set ::docked true
    }
  }

  Tracking this issue with valgrind, I noticed an error message already when a toplevel is created and then mapped to the screen:
  Valgrind says, after toplevel .t triggers the mapping:

  ==29387==  Address 0x11a246818 is 40 bytes inside a block of size 480 alloc'd
     ==29387==    at 0x10001150E: calloc (vg_replace_malloc.c:467)
     ==29387==    by 0x1039DAD1F: CGSNewWindowWithOpaqueShape (in /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.   framework/Versions/A/CoreGraphics)
     ==29387==    by 0x1016BAF03: _NSCreateWindowWithOpaqueShape2 (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
     ==29387==    by 0x10164F690: -[NSWindow _commonAwake] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
     ==29387==    by 0x10166D1C8: -[NSWindow _makeKeyRegardlessOfVisibility] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
     ==29387==    by 0x10166D13D: -[NSWindow makeKeyAndOrderFront:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
     ==29387==    by 0x1010C975E: XMapWindow (tkMacOSXSubwindows.c:153)
     ==29387==    by 0x10103238E: Tk_MapWindow (tkWindow.c:1658)
     ==29387==    by 0x10103B239: MapFrame (tkFrame.c:1782)
     ==29387==    by 0x1000CFC02: TclServiceIdle (in /Users/chris/Programmieren/lib/libtcl8.6.dylib)
     ==29387==    by 0x1000B340A: Tcl_DoOneEvent (in /Users/chris/Programmieren/lib/libtcl8.6.dylib)
     ==29387==    by 0x1010176CB: Tk_MainLoop (tkEvent.c:2131)
     ==29387==


  It is strange that Tk_MapWindow calls XMapWindow instead of TkWmMapWindow, because there is the following code:


     if (winPtr->flags & TK_WIN_MANAGED) {
             /*
              * Lots of special processing has to be done for top-level windows.
              * Let tkWm.c handle everything itself.
              */

             TkWmMapWindow(winPtr);
             return;
         }


  Can it be, that toplevel does not set TK_WIN_MANAGED correctly?


tkt_uuid: 220613ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 2
foundin: obsolete: 8.2.1
resolution: Fixed
title: resizing toplevel with menu generates fatal X Error
comment:
  OriginalBugID: 3377 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '2000-01-07'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Linux
  OSVersion: RedHat Linux 6.0
  FixedDate: '2000-01-07'
  FixedInVersion: 8.3b2


  Name:

  Jonas Beskow


  ReproducibleScript:

  menu .m

      .m add cascade -label [info patchlevel]

      . config -menu .m


      # resize the toplevel window vertically until only the menubar is

      visible (i.e. window area below the 

      # menubar is exactly of zero height - the error is especially easy to

      produce on window managers with 

      # dynamic content window resizing, e.g. KDE)


  ObservedBehavior:

  wish exits with the following error:

      X Error of failed request:  BadValue (integer parameter out of range for

      operation)

        Major opcode of failed request:  12 (X_ConfigureWindow)

        Value in failed request:  0x0

        Serial number of failed request:  180

        Current serial number in output stream:  181


  DesiredBehavior:

  wish continues to run with no error


  Patch:

  *** tkUnixWm.c  Thu Oct 14 15:31:06 1999

  --- tkUnixWm.c.fix      Thu Oct 14 15:30:52 1999

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

  *** 2074,2079 ****

  --- 2074,2080 ----

        TkWindow *wrapperPtr = wmPtr->wrapperPtr;

        TkWindow *winPtr = wmPtr->winPtr;

        TkDisplay *dispPtr = wmPtr->winPtr->dispPtr;

  +     Tk_ErrorHandler handler;


        /* 

         * Update size information from the event.  There are a couple of

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

  *** 2203,2212 ****

         * Make sure that the toplevel and menubar are properly positioned within

         * the wrapper.

         */

  ! 

        XMoveResizeWindow(winPtr->display, winPtr->window, 0,

              wmPtr->menuHeight, (unsigned) wrapperPtr->changes.width,

              (unsigned) (wrapperPtr->changes.height - wmPtr->menuHeight));

        if ((wmPtr->menubar != NULL)

              && ((Tk_Width(wmPtr->menubar) != wrapperPtr->changes.width)

              || (Tk_Height(wmPtr->menubar) != wmPtr->menuHeight))) {

  --- 2204,2215 ----

         * Make sure that the toplevel and menubar are properly positioned within

         * the wrapper.

         */

  !     handler = Tk_CreateErrorHandler(winPtr->display, -1, -1, -1,

  !                                   (Tk_ErrorProc *) NULL, (ClientData) NULL);

        XMoveResizeWindow(winPtr->display, winPtr->window, 0,

              wmPtr->menuHeight, (unsigned) wrapperPtr->changes.width,

              (unsigned) (wrapperPtr->changes.height - wmPtr->menuHeight));

  +     Tk_DeleteErrorHandler(handler);

        if ((wmPtr->menubar != NULL)

              && ((Tk_Width(wmPtr->menubar) != wrapperPtr->changes.width)

              || (Tk_Height(wmPtr->menubar) != wmPtr->menuHeight))) {


  PatchFiles:

  tkUnixWm.c




  fixed in 8.3b2. 
  -- 01/07/2000 hobbs


tkt_uuid: 1565937fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.4.13
resolution: Works For Me
title: -default option
comment:
  submitted by Uwe Kirschner uwe.kirschner@gmx.net

  Try this on Mac OS X:
  tk_messageBox -message "Hello world" -type yesnocancel -default 
  cancel

  will not work. But:

  tk_messageBox -message "Hello world" -type yesnocancel -default 
  no

  will work.

  It seems that setting -default to the last button of -type will cause the 
  bug. I compared the message.tcl in versions 8.4.10 and 8.4.13 and 
  discovered that there has been some extra -default behaviour introduced. 
  I could not find the exact cause, though.

  This bug applies to both 8.4.13 and 8.5.a4

  regards, Uwe


tkt_uuid: 1581932fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: Fixed
title: wm $win -alpha returns old value
comment:
  The following script simply fixes the window's alpha at 0.02, instead of 
  fading it in nicely. I believe this used to work some months ago.

  #!/usr/bin/wish
  toplevel .startup
  frame .startup.f -bg red -width 500 -height 500
  wm attributes .startup -alpha 0.02

  proc fadeIn {win increment} {
      set alpha [wm attributes $win -alpha]
      set alpha [expr {$alpha + $increment}]
      if {$alpha > 1.0} {
  return
      }
      puts $alpha
      wm attributes $win -alpha $alpha
      after 20 [list fadeIn $win $increment]
  }

  fadeIn .startup 0.02

  puts "done"


tkt_uuid: 2980137fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 58. [send]
priority: 5 Medium
foundin: None
resolution: None
title: support return options
comment:
  The various implementations of [send] have schemes
  to transport the errorInfo and errorCode values from
  script evaluation, but have never been updated to
  accommodate the full return options dictionary
  produced by evaluation in Tcl 8.5+ interps.


tkt_uuid: 220630ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: MacOS: Menu Cmds / Font Substitutions
comment:
  OriginalBugID: 3705 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-29'
  LastModified: '1999-12-14'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: 8.5.1
  Machine: iMac Rev.C
  FixedDate: '1999-12-14'
  FixedInVersion: 8.3b1


  Name:

  Peter Wilson


  Extensions:

  Dash-Patch for 8.2.2


  ReproducibleScript:

  1. Menu Cmds:  Disabled entry isn't completely greyed out and "..."->"......".


  . config -menu .mbar

  menu .mbar

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

  menu .mbar.file

  .mbar.file add command -label "Open..." -accel "Cmd-O" -state normal

  .mbar.file add command -label "New..." -accel "Cmd-N" -state disabled


  2. Font Substitution:  Some characters drawn as bitmaps


  font create tstFont -family Charcoal -size 40

  label .lbl -text "abcdefghijklmnopqrstuvwxyz\nABCDEFGHIJKLMNOPQRSTUVWXYZ"  -font tstFont

  pack .lbl


  3. Post Command: n/a


  ObservedBehavior:

  1. When a menu item with a shortcut is disabled, the text, but not the command

  string turns grey.  Bug is an unitialized variable.  Also, conversion of

  triple-dots to elipses results in 5 dots, not 3.  


  2. Some characters get displayed in a font other than the one requested. The

  "missing" characters would be drawn with bitmapped versions, instead. The

  particular characters lost differed between the 2 machines I tested.

  Bug is due to differing Font Records for bitmapped and outline fonts.


  3. Post commands do not get executed.


  (4. tkMacMenu.c contained nonASCII characters for special Mac symbols which were getting converted during local file handling... CVS and FTP transfers, etc.)


  DesiredBehavior:

  1.  Entire menu entry should be greyed and only one special elipsis character drawn in place of "..."


  2.  All characters should get drawn in same font.


  3.  Post commands executed prior to displaying the menu.


  (4. Special characters should be escaped.  I've converted them to \octal format.)


  Patch:

  diff -c ./tkMacFont.c /lheadev/pwilson/fv/tk8.2.2/mac/tkMacFont.c

  *** ./tkMacFont.cMon Nov 29 16:10:54 1999

  --- /lheadev/pwilson/fv/tk8.2.2/mac/tkMacFont.cFri Nov 26 14:38:36 1999

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

  *** 1721,1726 ****

  --- 1721,1730 ----

        unsigned char buf[16];

        int srcRead, dstWrote;

        Tcl_Encoding encoding;

  +     Handle fHandle;

  +     short theID;

  +     ResType theType;

  +     Str255 theName;


        subFontPtr->fontMap[row] = (char *) ckalloc(FONTMAP_BITSPERPAGE / 8);

        memset(subFontPtr->fontMap[row], 0, FONTMAP_BITSPERPAGE / 8);

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

  *** 1738,1775 ****

        fm.denom.v= 1;


    #if !defined(UNIVERSAL_INTERFACES_VERSION) || (UNIVERSAL_INTERFACES_VERSION < 0x0300)

  !     fontRecPtr = *((FontRec **) FMSwapFont(&fm)->fontResult);

    #else

  !     fontRecPtr = *((FontRec **) FMSwapFont(&fm)->fontHandle);

    #endif

  !     widths = (short *) ((long) &fontRecPtr->owTLoc 

  !         + ((long) (fontRecPtr->owTLoc - fontRecPtr->firstChar) 

  !         * sizeof(short)));

        isMultiByteFont = subFontPtr->familyPtr->isMultiByteFont;

  !         

  !     end = (row + 1) << FONTMAP_SHIFT;

  !     for (i = row << FONTMAP_SHIFT; i < end; i++) {

  !         if (Tcl_UtfToExternal(NULL, encoding, src, Tcl_UniCharToUtf(i, src), 

  !         TCL_ENCODING_STOPONERROR, NULL, (char *) buf, sizeof(buf), 

  ! &srcRead, &dstWrote, NULL) == TCL_OK) {

  !             

  !             if (((isMultiByteFont != 0) && (buf[0] > 31))

  !                 || (widths[buf[0]] != -1)) {

  !             if ((buf[0] == 0x11) && (widths[0x12] == -1)) {

  !                 continue;

  !             }

  !             

  !                 /* 

  !                  * Mac's char existence metrics are only for one-byte

  !                  * characters.  If we have a double-byte char, just 

  !                  * assume that the font supports that char if the font's 

  !                  * encoding supports that char.

  !                  */

  !                 

                    bitOffset = i & (FONTMAP_BITSPERPAGE - 1);

  ! subFontPtr->fontMap[row][bitOffset >> 3] |= 1 << (bitOffset & 7);

  !     }

  ! }

        }

    }

    

  --- 1742,1801 ----

        fm.denom.v= 1;


    #if !defined(UNIVERSAL_INTERFACES_VERSION) || (UNIVERSAL_INTERFACES_VERSION < 0x0300)

  !     fHandle = FMSwapFont(&fm)->fontHandle;

    #else

  !     fHandle = FMSwapFont(&fm)->fontHandle;

    #endif

  !     GetResInfo(fHandle, &theID, &theType, theName);

        isMultiByteFont = subFontPtr->familyPtr->isMultiByteFont;

  !     if( theType=='sfnt' ) {

  !     

  !             /*  Found an outline font which has very complex font record.  */

  !             /*  Let's just assume *ALL* the characters are allowed.        */

  !         

  !         end = (row + 1) << FONTMAP_SHIFT;

  !         for (i = row << FONTMAP_SHIFT; i < end; i++) {

  !             if (Tcl_UtfToExternal(NULL, encoding, src, Tcl_UniCharToUtf(i, src), 

  !                 TCL_ENCODING_STOPONERROR, NULL, (char *) buf, sizeof(buf),

  !                 &srcRead, &dstWrote, NULL) == TCL_OK) {

                    bitOffset = i & (FONTMAP_BITSPERPAGE - 1);

  !                subFontPtr->fontMap[row][bitOffset >> 3] |= 1 << (bitOffset & 7);

  !         }

  !     }

  !     } else {

  !     

  !             /*  Found an old bitmap font which has a well-defined record.     */

  !             /*  We can check the width table to see which characters exist.   */

  !         

  !         fontRecPtr = *((FontRec **) fHandle );

  !         widths = (short *) ((long) &fontRecPtr->owTLoc 

  !             + ((long) (fontRecPtr->owTLoc - fontRecPtr->firstChar) 

  !             * sizeof(short)));

  !             

  !         end = (row + 1) << FONTMAP_SHIFT;

  !         for (i = row << FONTMAP_SHIFT; i < end; i++) {

  !             if (Tcl_UtfToExternal(NULL, encoding, src, Tcl_UniCharToUtf(i, src), 

  !             TCL_ENCODING_STOPONERROR, NULL, (char *) buf, sizeof(buf), 

  !     &srcRead, &dstWrote, NULL) == TCL_OK) {

  !                 

  !                 if (((isMultiByteFont != 0) && (buf[0] > 31))

  !                     || (widths[buf[0]] != -1)) {

  !                 if ((buf[0] == 0x11) && (widths[0x12] == -1)) {

  !                     continue;

  !                 }

  !                 

  !                     /* 

  !                      * Mac's char existence metrics are only for one-byte

  !                      * characters.  If we have a double-byte char, just 

  !                      * assume that the font supports that char if the font's 

  !                      * encoding supports that char.

  !                      */

  !                     

  !                     bitOffset = i & (FONTMAP_BITSPERPAGE - 1);

  !             subFontPtr->fontMap[row][bitOffset >> 3] |= 1 << (bitOffset & 7);

  !         }

  !         }

  !     }

        }

    }

    

  diff -c ./tkMacMenu.c /lheadev/pwilson/fv/tk8.2.2/mac/tkMacMenu.c

  *** ./tkMacMenu.cMon Nov 29 16:17:07 1999

  --- /lheadev/pwilson/fv/tk8.2.2/mac/tkMacMenu.cMon Nov 29 16:17:31 1999

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

  *** 724,735 ****

        char *dStringText;

        int i;


  ! for (i = 0; i < length; text++, i++) {

            if ((*text == '.')

                && (*(text + 1) != '\0') && (*(text + 1) == '.')

                && (*(text + 2) != '\0') && (*(text + 2) == '.')) {

            Tcl_DStringAppend(dStringPtr, elipsisString, -1);

            i += strlen(elipsisString) - 1;

           } else {

            Tcl_DStringSetLength(dStringPtr,

    Tcl_DStringLength(dStringPtr) + 1);

  --- 724,736 ----

        char *dStringText;

        int i;


  ! for (i = 0; *text; text++, i++) {

            if ((*text == '.')

                && (*(text + 1) != '\0') && (*(text + 1) == '.')

                && (*(text + 2) != '\0') && (*(text + 2) == '.')) {

            Tcl_DStringAppend(dStringPtr, elipsisString, -1);

            i += strlen(elipsisString) - 1;

  +                 text += 2;

           } else {

            Tcl_DStringSetLength(dStringPtr,

    Tcl_DStringLength(dStringPtr) + 1);

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

  *** 751,762 ****

     *

     * We try the following special mac characters. If none of them

     * are present, just use the check mark.

  !  * '' - Check mark character

  !  * '´' - Bullet character

  !  * '' - Filled diamond

  !  * '*' - Hollow diamond

  !  * '*' = Long dash ("em dash")

  !  * '-' = short dash (minus, "en dash");

     *

     * Results:

     *None.

  --- 752,763 ----

     *

     * We try the following special mac characters. If none of them

     * are present, just use the check mark.

  !  * '' - Check mark character     (\022)

  !  * '' - Bullet character         (\245)

  !  * '' - Filled diamond           (\023)

  !  * '*' - Hollow diamond           (\327)

  !  * '' = Long dash ("em dash")    (\321)

  !  * '-' = short dash (minus, "en dash")

     *

     * Results:

     *None.

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

  *** 778,798 ****

        tkfont = Tk_GetFontFromObj(mePtr->menuPtr->tkwin,

            (mePtr->fontPtr == NULL) ? mePtr->menuPtr->fontPtr

        : mePtr->fontPtr);

  !         

  !     if (!TkMacIsCharacterMissing(tkfont, '')) {

  !     markChar = '';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '´')) {

  !     markChar = '´';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '')) {

  !     markChar = '';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '*')) {

  !     markChar = '*';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '*')) {

  !     markChar = '*';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '-')) {

        markChar = '-';

        } else {

  !     markChar = '';

        }

        return markChar;

    }

  --- 779,799 ----

        tkfont = Tk_GetFontFromObj(mePtr->menuPtr->tkwin,

            (mePtr->fontPtr == NULL) ? mePtr->menuPtr->fontPtr

        : mePtr->fontPtr);

  ! 

  !     if (       !TkMacIsCharacterMissing(tkfont, '\022')) {  /*  Checkmark   */

  !     markChar = '\022';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '\245')) {  /*  Bullet      */

  !     markChar = '\245';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '\023')) {  /*  Filled Diamond  */

  !     markChar = '\023';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '\327')) {  /*  Hollow Diamond  */

  !     markChar = '\327';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '\321')) {  /*  Long Dash   */

  !     markChar = '\321';

  !     } else if (!TkMacIsCharacterMissing(tkfont, '-'))    {  /*  Short Dash  */

        markChar = '-';

        } else {

  !     markChar = '\022';  /*  Everything missing... just throw up checkmark  */

        }

        return markChar;

    }

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

  *** 1178,1184 ****

                && (ENTRY_COMMAND_ACCEL 

                == (mePtr->entryFlags & ENTRY_ACCEL_MASK))) {

            char *accel = Tcl_GetStringFromObj(mePtr->accelPtr, NULL);

  !     SetItemCmd(macMenuHdl, index, accel[((EntryGeometry *)

        mePtr->platformEntryData)->accelTextStart]);

        }

        }

  --- 1179,1185 ----

                && (ENTRY_COMMAND_ACCEL 

                == (mePtr->entryFlags & ENTRY_ACCEL_MASK))) {

            char *accel = Tcl_GetStringFromObj(mePtr->accelPtr, NULL);

  !     SetItemCmd(macMenuHdl, base + index, accel[((EntryGeometry *)

        mePtr->platformEntryData)->accelTextStart]);

        }

        }

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

  *** 3574,3580 ****

        Tk_FontMetrics entryMetrics;

        int adjustedY = y + padY;

        int adjustedHeight = height - 2 * padY;

  -     int state;


        /*

         * Choose the gc for drawing the foreground part of the entry.

  --- 3575,3580 ----

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

  *** 3605,3611 ****

            }

        }


  ! if (((parentDisabled || (state == ENTRY_DISABLED)))

    && (menuPtr->disabledFgPtr != NULL)) {

        gc = mePtr->disabledGC;

        if (gc == NULL) {

  --- 3605,3611 ----

            }

        }


  ! if (((parentDisabled || (mePtr->state == ENTRY_DISABLED)))

    && (menuPtr->disabledFgPtr != NULL)) {

        gc = mePtr->disabledGC;

        if (gc == NULL) {

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

  *** 4398,4404 ****

        FixMDEF();


  !     Tcl_ExternalToUtf(NULL, NULL, "É", -1, 0, NULL, elipsisString,

        TCL_UTF_MAX + 1, NULL, NULL, NULL);

    }

    

  --- 4398,4404 ----

        FixMDEF();


  !     Tcl_ExternalToUtf(NULL, NULL, "\311", -1, 0, NULL, elipsisString,

        TCL_UTF_MAX + 1, NULL, NULL, NULL);

    }

    

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

  *** 4425,4428 ****

  --- 4425,4458 ----

        /*

         * Nothing to do.

         */

  + }

  + 

  + /*

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

  +  *

  +  * TkpPreprocessMacMenu --

  +  *

  +  *Handle preprocessing of menubar if it exists.

  +  *

  +  * Results:

  +  *None.

  +  *

  +  * Side effects:

  +  *All post commands for the current menubar get executed.

  +  *

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

  +  */

  + 

  + void TkpPreprocessMacMenu( void );

  + void TkpPreprocessMacMenu( void )

  + {

  +     TkMenuReferences *menuBarRefPtr;

  + 

  +     if( currentMenuBarName != NULL ) {

  +         menuBarRefPtr = TkFindMenuReferences(currentMenuBarInterp,

  +             currentMenuBarName);

  +         if( (menuBarRefPtr != NULL) && (menuBarRefPtr->menuPtr != NULL) ) {

  +             TkPreprocessMenu(menuBarRefPtr->menuPtr->masterMenuPtr);

  +         }

  +     }

    }

  diff -c ./tkMacWindowMgr.c /lheadev/pwilson/fv/tk8.2.2/mac/tkMacWindowMgr.c

  *** ./tkMacWindowMgr.cMon Nov 29 16:10:58 1999

  --- /lheadev/pwilson/fv/tk8.2.2/mac/tkMacWindowMgr.cFri Nov 26 14:38:38 1999

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

  *** 207,216 ****

  --- 207,219 ----

        {

    int oldMode;

    KeyMap theKeys;

  + void TkpPreprocessMacMenu(void);


    GetKeys(theKeys);

    oldMode = Tcl_SetServiceMode(TCL_SERVICE_ALL);

    TkMacClearMenubarActive();

  + /* POSTCOMMAND??? */

  + TkpPreprocessMacMenu();

    TkMacHandleMenuSelect(MenuSelect(eventPtr->where),

    theKeys[1] & 4);

    Tcl_SetServiceMode(oldMode);


  PatchFiles:

  tkMacFont.c

      tkMacMenu.c

      tkMacWindowMgr.c




  all applied for 8.3b1 
  -- 12/14/1999 hobbs


tkt_uuid: 969636ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 06. Canvas Postscript
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: None
title: embedded windows representation offset (horiz.))
comment:
  This also applies to version 8.4.6 (windows version)

  When a postscript file is generated using embedded 
  canvas windows, any embedded window having an offset 
  scrollrange (e.g. {-100, -100, 100 100} will be 
  represented correctly in the vertical direction, but the 
  horizontal direction is still displayed from the absolute 
  zero point.

  An example:
  pack [canvas .c]
  .c create rectangle 1 1 300 300 -fill wheat
  canvas .c1 -width 201 -height 201 -bg white \
             -highlightthickness 0
  .c create window 20 20 -anchor nw -window .c1
  .c1 config -scrollregion {-100 -100 100 100}
  #axis system
  .c1 create line -100 0 100 0
  .c1 create line 0 -100 0 100
  update
  .c postscript -file test.ps


tkt_uuid: 220256ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 1 Zero
foundin: obsolete: 8.2.2
resolution: Invalid
title: console is viewed as redirected input
comment:
  OriginalBugID: 3667 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-23'
  LastModified: '1999-11-29'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  OSVersion: Windows95
  Machine: Brandless clone Cyrix686
  ClosedDate: '1999-11-29'


  Name:
  Jean-Pierre Vial

  Extensions:
  Pure Tcl or Tk 8.2.2

  CustomShell:
  None

  Comments:
  A test under Linux (with a much older version of Tk) works fine,
  but obviously the process is quite different: with linux the console
  is an ordinary xterm window, with Windows95 Wish opens its own console,
  this is probably the origin of the problem.

  ReproducibleScript:
  I have applications (in C) which react differently
  in interactive mode and in shell scripts.
  They choose the appropriate mode via an <<isatty>> test.
  With tclsh, everything is OK
  with wish, the console is not considered as a tty but as a file. 
  Here is a C test file (tsttty.c)

  #include "stdio.h"
  #include "io.h"
  int main(void){
  if (isatty(fileno(stdin)))
  printf("stdin is the console: interactive mode\n");
  else printf("stdin is a file: automatic mode without prompt or messages\n");
  return 0;
  }

  ObservedBehavior:
  % tsttty
  stdin is a file: automatic mode without prompt or messages
  % 

  [this is done with Wish (= Tk 8.2.2), in interactive mode in the wish console]

  DesiredBehavior:
  % tsttty
  stdin is the console: interactive mode
  %

  (This is done with tclsh: no problem here)



  There is no problem here, this is a conscious design decision,
  that wish not be tied to the console.  See the comp.lang.tcl
  newsgroup for solutions on how to modify the makefile to put
  wish into console mode (which would pop up a DOS box with each
  invocation). 
  -- 11/29/1999 hobbs


tkt_uuid: 1510796fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.4.12
resolution: Invalid
title: Embed Tk widgets in VisualC++, When changed the colourdepth
comment:
  As the bug[1123042] described , Yes ,this bug has been 
  solved in the version Tk8.4.12 ,but when i embed the 
  tk widgets in MFC dialog,after i changed the 
  colordepth the tk widgets does not display correct. 
  Even after i refreshed the tk event ,it also does not 
  display correct . 


tkt_uuid: 2782346fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
foundin: None
resolution: None
title: ttk::notebook configure styles for each tab
comment:
  It would be nice if one could specify a style for each tab in ttk::notebook instead of the default TNotebook.Tab. This would allow to add tab scrolling at script level, create tabs with different buttons (for example, like firefox tabs)   


tkt_uuid: 3313032fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: ttk::spinbox doesn't expand its height on Linux
comment:
  The height of the entry field in a spinbox widget remains constant even when it should grow to fill its available space.

  ttk::frame .fm
  ttk::spinbox .fm.sb
  pack .fm.sb -fill both -expand 1
  pack .fm -fill both -expand 1

  #Other widgets, entry, spinbox, ttk::entry expand to fill the available vertical space. (Noticed on Linux)


tkt_uuid: 3607336fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 63. Tk_Win Functions
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: None
title: Tk_Window object is equal to NULL
comment:
  Hello,
  I need some help to compile my project. I use Tcl 8.4.13 and Tk 8.4.13. 
  When I run my programm I have a core file. I read it with gdb and it's crashed at this line :
      Et_Display = Tk_Display(mainWindow);
  and when I print mainWindow :
  >> (gdb) print mainWindow
  $1 = (Tk_Window) 0x0

  Why this variable is equal to NULL ? 
  Thank you for your support.

  Sallem
   


tkt_uuid: 2963397fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: Wont Fix
title: Scrollbar config not working
comment:
  scrollbar .sb
  pack .sb
  .sb configure -borderwidth 3
  .sb configure -elementborderwidth 3
  .sb configure -relief flat
  .sb configure -activerelief flat

  Win XP
  these configurations actually have no effect.

  thx


tkt_uuid: 220101ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1a2
resolution: Invalid
title: file cmd fails in threaded apps
comment:
  OriginalBugID: 562 Bug
  Version: 8.1a2
  SubmitDate: '1998-04-15'
  LastModified: '1999-04-05'
  Severity: MED
  Status: Closed
  Submitter: hershey
  ChangedBy: redman
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-04-05'


  Subject:      Tcl 8.1 Thread-safety issue:  "file" commands are
  broken.
  From:         ranga@cs.umd.edu (M.Ranganathan)
  Date:         1998/04/10
  Message-ID:   <6glmc1$6kv@zagnut.cs.umd.edu>
  Newsgroups:   comp.lang.tcl

  There is a small bug with the Makefile for the unix tcl 8.1.a2
  distribution.

  The Makefile for UNIX should include -D_REENTRANT -- otherwise
  various "file" commands do not work when a multi-threaded
  extension is built. The error is caused by the errno global
  variable
  which the TclMakeDir subroutine looks at. While using pthreads,
  errno
  is a macro. The macro does not kick in unless -D_REENTRANT is
  defined.
  I suspect other things like this would also break.

  The problem can be easily fixed by adding -D_REENTRANT to CFLAGS.

  Ranga.



  We need to get the OS version.
  Some platfroms have system headers that are altered by the REENTRANT flag.  We need to  determine if this is what is happening.  03/26/1999 11:09 - surles -
  03/27/1999 15:50 - redman - The configure script already checks for it and adds it when it should.  This appears to have been fixed already.


tkt_uuid: 3512539fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 99. Other
priority: 5 Medium
foundin: None
resolution: None
title: .. is silently accepted in widget paths
comment:
  A child widget of the main application window can be created with a leading ".." in the pathname;  this is silently interpreted as "." and the widget creation command returns the fixed path.

  While I think this behavior is sensible - it simplifies a generic create a child window operation to "set widget_cmd [label $parent.name]" - the behavior is apparently undocumented.  The behavior should either be documented/supported so that it can be relied on, or eliminated so that it does not become entrenched when people accidentally discover it.


tkt_uuid: 3403387fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: Canvas Text Clipping
comment:
  I have a specific rectangle that I want text to appear in, with any excess text being clipped ("overflow: hidden" in CSS/HTML terms); I'm told that I can either not limit width, and the text overflows left and right, or I can limit width, and the text overflows top and bottom.

  A screenshot of the problem that I'm trying to solve is attached.

  It would be really nice if I could limit the width *and* the height -- if the height limit was "number of lines of wrapped text" rather than pixels then that would be easy to use and probably easier to implement (I would imagine incrementing a counter with each line wrap, then breaking out of the loop when the number of lines reaches the limit)

  If the bounding box could be specified in a way that scales when canvas.scale() gets called, that would be even better.

  For the moment I'm manually storing a second copy of all the bits of text on screen, then manually calculating the width and truncating the text on every rescale -- but this seems like I'm duplicating a lot work that Tk has already done (it is already storing a copy of the full text, calculating the width, and then truncating in order to wrap the text -- all I want on top of that is for it to stop rendering after one line)


tkt_uuid: 1105433fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 83. Mac OS X Build
priority: 4
foundin: obsolete: 8.4.9
resolution: None
title: Contingently dead feature: three-button mouse emulation
comment:
  I'm running a (primarily) Tcl/Tk program called NMRView, from 
  within Aqua. I need to 'apple'-click to emulate a right click, and 
  'option'-click to emulate a middle button. I really do!

  This worked fine until I updated my Tcl to 8.4.9; concurrent with 
  that update, I lost the aforementioned functionality. Because I first 
  noticed the flaw on my PowerBook G4, and not our group's G5, I 
  thought a hardware glitch. However, the problem is now 
  noticable on the G5. So here we are.

  Basically, I try to right click, and nothing happens. It may be 
  relevant that I have no problem using modifier keys in a non-Tcl/
  Tk, Aqua program, or in Tcl/Tk programs ran within X11. I have not 
  tried reproducing this problem in another Tcl/Tk program ran 
  within Aqua - I don't have such a program (to my knowledge). 

  The applications I was using was identical, comparing the two 
  computers (Tcl 8.4.9 BI installed with the installer; same version of 
  NMRView). Both machines are running Panther. 

  Any suggestions? It's my first bug submission, so I hope I've 
  provided enough information.


tkt_uuid: 578654ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Canvas lines -smooth config problem
comment:
  Tcl bug 571682 (submitted by someone to the wrong
  project) can really described as a complaint that the
  following code doesn't work:

    pack [canvas .c]
    .c create line 0 0 0 2 2 2 -smooth 1 -tag src
    set s [.c itemcget src -smooth]
    .c create line 1 1 1 3 3 3 -smooth $s

  Problem is that although -smooth accepts only boolean
  values for -smooth at the moment, "-smooth 1" gets
  reported back as "bezier".  The problem (in
  tkCanvUtil.c) is that tkBezierSmoothMethod is not part
  of the "smoothMethod" assoc-data (maybe a missing init
  funcion?)

  The documentation in canvas.n needs updating too.


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


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

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

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

  Then you get the failure:

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

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

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


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

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

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

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


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

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

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

  set x

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

  destroy .t


  This script seems to be minimal.

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

  x-up up

  but is is:

  up

  most of the time, although not always!


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


  Clueless...


tkt_uuid: 2912603fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: Support for complex polygons in canvas
comment:
  [This was originally Tcl FRQ #1266238]
  This is a request for support of complex polygons in canvases. 

  RATIONALE:
  Such grapic items are common in computer graphics.

  SUGGESTED IMPLEMENTATION

  Alternative 1: Extend the current polygon item.

  The current "create polygon" command is extended so the coordinates can be specified as a list of lists of coordinates, each list comprise a part of the polygon, with the outer polygin first. This alternative requieres that the current command determines what kind of list it has as parameter, and takes the appropriate action.

  Aternative 2: New compound item.

  New command "create compond <list> <options>...", with syntax as "create polygon" as above where <list> is a list of list of coordinates.

  Alternative 3: New complex item

  New command "create complex <ti1> <ti2> ..." where <ti?> is a tag or identifier identifying existing items in the canvas. These items may now be considered as a 'group', with a single identity. It may then be possible to specify as an option "-eofill 1" to specify that polygons in the group is to be painted with even-odd fill.


tkt_uuid: 1692395fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: None
title: Poor listbox performance in Tk 8.5a6
comment:
  The following simple script demonstrates a siginificant listbox performance regression in Tk 8.5a6:

  pack [listbox .lb]
  puts [time {
      for {set n 0} {$n < 100000} {incr n} {
          .lb insert end "This is item #$n"
      }
  }]

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

  1793963 microseconds per iteration

  Compare this with the time needed by Tk 8.4.13:

  1126718 microseconds per iteration

  This is an unacceptable performance regression.


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: 694528ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 06. Canvas Postscript
priority: 5 Medium
foundin: None
resolution: None
title: Postscript text too small
comment:
  The canvas postscript command outputs text that is the 
  wrong size, in relation to other canvas elements. The 
  size is too small by a factor of [tk scaling].
  A detailed description and test script are on the wiki,
  http://mini.net/tcl/8483

  Ian Gay
  gay@sfu.ca


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: 220729ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: 'ctrl-backspace' appears as 'ctrl-???' in bindings
comment:
  OriginalBugID: 5090 Bug
  Version: 8.3
  SubmitDate: '2000-04-14'
  LastModified: '2000-04-14'
  Severity: MED
  Status: Released
  Submitter: ericm
  ChangedBy: ericm
  OS: All Windows
  FixedDate: '2000-04-14'
  FixedInVersion: 8.3.1


  bind . <KeyPress> [list puts stdout "You pressed %K"]

  Go to the '.' window, hit 'backspace' a few times, then hit control-
  backspace a few times.  I get the following output with Tk 8.3.0 (_not_
  with 8.2.x)

  ObservedBehavior:
  You pressed BackSpace
  You pressed BackSpace
  You pressed BackSpace
  You pressed BackSpace
  You pressed Control_L
  You pressed ??
  You pressed ??
  You pressed ??
  %

  DesiredBehavior:
  Tk 8.2.3 gives:
  % bind . <KeyPress> [list puts stdout "You pressed %K"]
  You pressed BackSpace
  You pressed BackSpace
  You pressed BackSpace
  You pressed Control_L
  You pressed BackSpace
  You pressed BackSpace
  You pressed BackSpace
  You pressed BackSpace


  This was a side effect of the dead-key handling that was added in Tcl/Tk 8.3.0.  The Windows implementation was using a more correct Windows API call to get some information about the key that was pressed, and the code was not handling all the possible returns from that API call.

  I fixed this in CVS, and the fix will go out with 8.3.1.

  W.R.T. the delay in this bug showing up, it seems that this bug report slipped through the cracks -- we were having some server difficulties around the time that you submitted it, and it may just not have made it through.

  - eric


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

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

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


tkt_uuid: 220338ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.1a1
resolution: Fixed
title: cascade menus cannot be disabled properly, and sometimes disappear
comment:
  OriginalBugID: 547 Bug
  Version: 8.1a1
  SubmitDate: '1998-03-18'
  LastModified: '2000-01-07'
  Severity: MED
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: All
  FixedDate: '2000-01-07'
  FixedInVersion: 8.3b1


  > I reported this to this newsgroup a month or so ago for a1, but here
  > it is again.  Disabling/enabling the state of a submenu label in a
  > menubar is completely incorrect.
  > 
  > Wish8.1a1 or Wish8.1a2:
  > 

  menu .menubar
  .menubar add cascade -menu .menubar.m -label "Test"
  menu .menubar.m
  .menubar.m add cascade -menu .menubar.m.buggy -label "Buggy state"
  . configure -menu .menubar
  menu .menubar.m.buggy
  .menubar.m.buggy add command -label "Blah"

  # now test the menu; it works fine
  # Here's where the bugs start

  .menubar.m entryconfigure 1 -state disabled
  > unknown option "menu"
   
  # That's an odd bug.  No idea where that error comes from
  # Let's try again:
  .menubar.m entryconfigure 1 -state disabled

  # It works now!  However it does the wrong thing
  # Look at the menu.  The 'submenu triangle thing'
  # has vanished!  Let's try to enable the item again

  .menubar.m entryconfigure 1 -state normal

  # Oops.  Our submenu has gone.  We have to rebuild the
  # menu from scratch.
   
  >  Vince. <darley@fas.harvard.edu>


  There are two bugs here.  One is a typo, where the string "menu" is hardcoded instead of the string "menus", causing the error message
  'unknown option "menu"'.  Once that's fixed, other problems crop up for which there's no easy fix...
  ----
  First bug is fixed.
  Second bug needs to be verified.  It did not appear on NT or Solaris, but should be tested iin Win98 with large fonts enabled.  03/26/1999 11:07 - surles -
  ---
  This no longer is a problem in 8.3b1, and was likely fixed earlier. 
  -- 01/07/2000 hobbs


tkt_uuid: 220649ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.3b1
resolution: Fixed
title: event generate -warp 1 can cause a segv
comment:
  OriginalBugID: 4004 Bug
  Version: 8.3b1
  SubmitDate: '2000-01-11'
  LastModified: '2000-01-12'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: NT server 4 patchlevel 5
  Machine: Dual PII-400, 360 megs o' RAM
  FixedDate: '2000-01-12'
  FixedInVersion: 8.3b2


  Name: Bryan Oakley

  ReproducibleScript:
  button .b -text "Exit" -command exit
  pack .b

  after idle event generate .b <Motion> -x 1 -y 1 -warp 1

  ObservedBehavior:
  When I run the script, I get a segmentation violation

  DesiredBehavior:
  no segmentation violation 
  I also expect to see the pointer warp to the button.



  This is because the window has not yet been mapped, and thus the
  Windows HWND is still null.  This will be fixed, but the whole
  behavior is likely to change such that -warp requires that the
  window be mapped first, which means the user will have to put in
  an update, or put the -warp in a <Map> event. 
  -- 01/11/2000 hobbs
  The fixed was to add a check for Tk_IsMapped(tkwin), to make
  sure that the window has been mapped.  This also means that
  -warp, now by def'n, doesn't do anything if the window is not
  mapped (which makes sense).  The user would then get rid of
  the 'after idle' and add a:
      tkwait visibility .b
  to make the script correct (this will actually make 8.3b1 not
  core as well). 
  -- 01/12/2000 hobbs


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


tkt_uuid: 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: 2368195fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: None
resolution: None
title: paneconfigure not setting TCL_ERROR for unexisting window
comment:
  Hi,

  When calling paneconfigure for a panedwindow with a non existing window it doesn't set TCL_ERROR.

  Based on the version found here: http://tktoolkit.cvs.sourceforge.net/viewvc/tktoolkit/tk/generic/tkPanedWindow.c?revision=1.37&view=markup I see it doesn't check for tkwin being NULL (line 683) which it could then set TCL_ERROR and be happy since the error message was already set by Tk_NameToWindow.


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: 1591488fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 53. [selection]
priority: 5 Medium
foundin: obsolete: 8.5a5
resolution: None
title: test suite tests 10.2, 11.1 failed
comment:
  built cvs head tk 8.5 on solaris 2.9 using sun c
  compiler; run test suite back to win xp via exceed
  10.0.0.12.

  select.test

  ==== 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}
  ---- 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: 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: 940209ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Out of Date
title: bind documentation refers to X11 docs
comment:
  The [bind] documentation refers the reader to any
  X-windows documentation to learn about what it means to
  bind to <Map>, <Unmap>, <Visibility>, etc. events. 
  These should at least be explained briefly in Tk's
  documentation, even if external resources are suggested
  for further reading.


tkt_uuid: 220616ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.2.1
resolution: Fixed
title: Tk crashed with NULL pointer reference on exit
comment:
  OriginalBugID: 3402 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '2000-02-09'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3236
  OS: Windows NT
  FixedDate: '2000-02-09'
  FixedInVersion: 8.3


  Name:

  Murugasamy


  CVS:

  RCS: @(#) $Id: tkMenu.c,v 1.5 1999/04/21 21:53:26 rjohnson Exp $


  CustomShell:

  Refer to section 9.


  Comments:

  The variables newObjv[0] and newObjv[1]in function DestroyMenuInstance

      are incremented without checking for NULL.


      In the first place these objects should not be NULL.


  ReproducibleScript:

  When menu entries which has sub-menus are deleted and added with the

      same name, TK chashes with NULL pointer memory read.


  ObservedBehavior:

  On exit the tk displays the following error:

      The instruction at "0x00445bda" referenced memory at "0x00000000". The

      memory could not be "read".


  DesiredBehavior:

  Fix the NULL pointer reference.


  Patch:

  File: generic\tkMenu.c

  Function: DestroyMenuInstance

  Old lines:

      for (; cascadePtr != NULL; cascadePtr = nextCascadePtr) {

      nextCascadePtr = cascadePtr->nextCascadePtr;


      if (menuPtr->masterMenuPtr != menuPtr)

      Tcl_Obj *menuNamePtr = Tcl_NewStringObj("-menu", -1);


  Fixed Lines:

      for (; cascadePtr != NULL; cascadePtr = nextCascadePtr) {

      nextCascadePtr = cascadePtr->nextCascadePtr;


      if (menuPtr->masterMenuPtr != menuPtr 

      && cascadePtr->menuPtr->masterMenuPtr->entries[cascadePtr->index]->namePtr != NULL) {

      Tcl_Obj *menuNamePtr = Tcl_NewStringObj("-menu", -1);


  PatchFiles:

  generic\tkMenu.c




  A real snippet of code to reproduce this would have been much more
  useful.  I cannot reproduce this.  I have placed checks in
  DestroyMenuInstance to see if the newObjv args aren't NULL before
  changing the ref count.  Bug 3236 shows a related problem, with
  the same bug fault, but also no script, and has a different patch
  (from the same submitter). 
  -- 02/09/2000 hobbs


tkt_uuid: 220431ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 33. Generic Dialog Support
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Event loop freezes on standard dialogs
comment:
  OriginalBugID: 1212 Bug
  Version: 8.0.4
  SubmitDate: '1999-02-16'
  LastModified: '2000-02-01'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 715 830 2892
  OS: All Windows
  Machine: X86
  FixedDate: '2000-02-01'
  FixedInVersion: 8.3


  Name:
  Kevin B. Kenny

  Extensions:
  Tk 8.0.4 ; no other relevant extensions

  CustomShell:
  Script fails on an unmodified core release.

  ReproducibleScript:
  # If any of the standard dialogs comes up before the main window, the
  # Tk application's event loop on Win95/98 fails to handle events on the
  # main window and its children.  The following script illustrates the problem:

  set fileTypes {
      {{All Files} *}
  }
  grid [text .t -font {Courier}]
  grid [button .ok -text OK -command exit]
  set fileName [tk_getOpenFile  -filetypes $fileTypes  -title "Select file to display"]
  set f [open $fileName r]
  while {[gets $f line] >= 0} {
      .t insert end $line {} \n
  }
  close $f

  ObservedBehavior:
  The main window is "dead."  Mouse clicks and keyboard actions anywhere
  within the window and its descendants are ignored; for instance, clicking
  the "OK" button does nothing.

  DesiredBehavior:
  The main window should respond normally after the file selection dialog
  is dismissed.



  Verified on 8.2.0. 
  -- 08/20/1999 hobbs
  A work-around is to call 'update' before the first call to
  the dialog.  Problem only reproducable on Windows 
  -- 08/20/1999 hobbs
  The problem is actually restricted to the parent of the dialog
  that pops up, and only when the dialog is created before the
  parent is ever first mapped.  Windows would set it to disabled,
  then Tk would create a new wrapper, for which Windows wouldn't
  be aware, and you were left with a "disabled" toplevel.  This is
  fixed in 8.3.0, for all native Windows dialogs. 
  -- 02/01/2000 hobbs


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

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

  ==> segmentation fault

  Low priority, as this is an unlikely scenario.


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

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


tkt_uuid: 1202684fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 06. Canvas Postscript
priority: 5 Medium
foundin: None
resolution: None
title: Postscript output does not support all UNICODE characters
comment:
  The following script produces a square-root sign on the 
  canvas, but the postscript file contains a ?. This seems 
  to occur for any character outside the ordinary ASCII 
  table:

  pack [canvas .c]
  .c create text 100 100 -text \u221a
  .c postscript -file sqrt.ps

  Excerpt from the postscript file:

  100 168 [
  [(?)]
  ] 13 -0.5 0.5 0 false DrawText

  (a question mark instead of whatever UNICODE 221a 
  ought to be)


tkt_uuid: 1591704fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 16. [scrollbar]
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: None
title: PR 778511 needs to be reopened:Elide text scrolling doesn't
comment:
  PR 778511 (which has been closed) is still a problem. I see it in two 
  cases:
  - MacOS X 10.4.7 running Aqua Tcl/Tk 8.4.13.
  - Linux running Tcl/Tk 8.4.7

  PR 778511 include a demo script that works well (once you translate 
  the html entities). I will attach a translated version to speed up testing.

  -- Russell


tkt_uuid: 1055423fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 08. [(label)frame] and [toplevel]
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: Improve doc for frame -width/-height
comment:
  It should be documented better that frame's (and its
  peers')
  -width (and -height) is total size, including -bd/-pad.
  That is different from how e.g. canvas' -width work.

  Also, a note on how frame's -width interact badly with
  geometry managers would be good.


tkt_uuid: 3567283fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: obsolete: 8.6b3
resolution: Fixed
title: Incompatible pointer cast in tkWinWm.c
comment:
  While building 32-bit Tk from checkout [42c5de9b] (= core-8-6-b3-rc 2012/09/13) with MSVC2010 on Windows 7:

  tk\win\..\win\tkWinWm.c(5529) : warning C4133: 'function' : incompatible types - from 'TkWindow *' to 'Tk_Window'


tkt_uuid: 220396ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.1a2
resolution: Fixed
title: Disabled menu entries gets enabled
comment:
  OriginalBugID: 860 Bug
  Version: 8.1a2
  SubmitDate: '1998-11-25'
  LastModified: '1998-12-10'
  Severity: MED
  Status: Released
  Submitter: stanton
  ChangedBy: admin
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1998-11-25'
  FixedInVersion: 8.1b1


  In tk8.1a2 disabled menu entries gets reenabled as soon as you pass
  the cursor over them. The attached patch fixes this.

  Patch on the website as
  /patches/tk8.1a2/tkMenu.c.2.txt


tkt_uuid: 3003892fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: None
priority: 5 Medium
severity: Minor
foundin: None
resolution: None
title: TCLDIR default when building with makefile.vc
comment:
  Building Tk on windows require TCLDIR to be specified. TCLDIR can get a meaningful default as almost always tcl and tk source directories are placed in the same directory.


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: 3464070fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.6b2
resolution: None
title: MenuNewEntry() return NULL -> no error msg
comment:
  Noticed when reviewing 3235356, 3460976.

  In the rare case when a new menu entry cannot
  be created, the TCL_ERROR returned by various
  menu commands is not accompanied by any error
  message, code, etc.


tkt_uuid: 2473895fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: None
title: TIP141 not yet implemented
comment:
  When -multiple is given, we still treat -initialfile as a single filename instead of as a list of names. At very least, should use first element.

  Notes: doing more requires deep hacking on Win, unknown for OSX, easy(ish) for Unix.


tkt_uuid: 1414025fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 07. [entry]
priority: 5 Medium
foundin: None
resolution: None
title: thin entry insertion cursor not visible
comment:
  In an entry widget with -insertwidth 1 -justify right,
  the insertion cursor is not visible after the last
  character.  The same problem occurs if the entry is not
  right-justified, but full:

      entry .e -insertwidth 1 -width 2
      .e insert end "00"

  In both cases, it is the -insertwidth 1 setting that
  makes the cursor disappear after the last character. 
  With the setting -insertwidth 2, the widget behaves as
  expected.  The bug is present on all platforms.

  Actually, this bug report partly duplicates the one
  with the number #643823, concerning right-justified
  entry widgets on the Macintosh.  It looks like
  (contrary to what was suspected in connection with that
  bug) the reason of the reported behavior on the Mac was
  not the platform, but the -insertwidth 1 setting, which
  is the default on Mac OS X Aqua.


tkt_uuid: 220392ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Performance problem in Tk: hidden windows do excessive redisplay
comment:
  OriginalBugID: 791 Bug
  Version: 8.0.4
  SubmitDate: '1998-11-04'
  LastModified: '1999-12-14'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-12-14'
  FixedInVersion: 8.2.2


  There's a problem with the entry widget, try this:

          pack [entry .e -textvariable foo]
          set foo abcdefgh
          foreach i {0 1 2 3 4 5 6 7 8 9} {set foo $foo$foo}
          focus .e
          update
          # this is what ^E does
          puts [time [tkEntrySetCursor .e end; update]]

  The window with the letters in pops up almost immediately, but I've
  typed all this and the simulated ^E still hasn't come back.  Actually,
  the reported time was 127 microseconds, but in that 127 microseconds I
  started up wish4.2 to see if the bug was there as well.  It is.

  There's a possibly related problem with geometry management.  If I
  have a stack of text widgets all the same size managed by the placer
  (basically these windows are all on top of each other), then a change
  in geometry of the enclosing window seems to take an age.  It gets
  up to a second or two when I get to 25 windows which seems a trifle
  excessive.  I get the impression that all these text widgets are busily
  re-configuring and re-drawing themselves even though they aren't
  actually visible.  I don't have anything more concrete than this I'm
  afraid.



  The entry widget problem is likely due to an overaggressive
  accuracy check (in a while loop) in the entry widget bindings.
  This was solved in 8.2.2. 
  -- 12/14/1999 hobbs


tkt_uuid: 3427984fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: None
title: Cocoa support for TIP 382
comment:
  Cocoa doesn't seem to offer a simple flag
  interface to support the -confirmoverwrite
  option to [tk_getSaveFile], but a possible
  implementation approach is outlined here:

  http://stackoverflow.com/questions/1930352/nssavepanel-squelching-the-confirm-replace-dialog/2390780#2390780

  Leaving the RFE here for someone interested to
  react to.


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: 3105495fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 22. Style Engine
priority: 5 Medium
foundin: None
resolution: Wont Fix
title: Notebook Tabs on Mac Drawn in Center
comment:
  On the Mac, the tabs in a Notebook are drawn centered instead of aligned on the left (like PC and Linux).

  Here is an example script:

  ttk::notebook .n
  pack .n -side top -fill both -expand true
  frame .f1
  frame .f2
  .n add .f1 -text "Frame1"
  .n add .f2 -text "Frame2"


tkt_uuid: 220142ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Invalid
title: grab bug
comment:
  OriginalBugID: 1496 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-12'
  LastModified: '2000-01-27'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.5.1
  Machine: Other
  ClosedDate: '2000-01-27'


  Name: steve

  Extensions: expect 8.0.4

  ReproducibleScript:
      running expectk - same under wish
      
      from menu command call proc to create child window
      from bind double-click listbox call same proc to create child window
      
      the grab gets set to child window everytime using menu option
      so that user can't touch parent window ever.
      
      the grab does not get set to child window everytime using double click
      from listbox.
      
      in other words if the user double clicks the grab does not get
      set everytime - seems to be hit and miss situation.

  ObservedBehavior:
      no errors at all ( no stack traces) - the behavior is not consistent
      when setting local grab using the same procedure
      via different call points/events

  DesiredBehavior:
      when i call this proc to produce a child window from either
      a menu command or a bind command the grab should work all the
      time.

   Actual code is necessary to really evaluate this one.  I suspect
  that the problem is the user may have set up the window to be
  grabbed when a mouse button could be down.  This is a special
  situation, so if the user needs to set the grab in a case like
  that, it has to be coded carefully. 
  -- 01/27/2000 hobbs


tkt_uuid: 2971081fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 09. [listbox]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: listbox returns wrong active element index
comment:
  The result of "pathName index active" when called as a result of a <<ListboxSelect>> event triggered when the listbox is clicked on, always returns the index of the last active element in the listbox, rather than the current active element.

  Example code to illustrate the problem:

  package require Tk
  set lv "element_0 element_1 element_2"
  proc lb_report {path} {puts "current selection: [$path curselection]" ; puts "active index: [$path index active]"}
  listbox .lb -listvariable lv
  bind .lb <<ListboxSelect>> "lb_report %W"
  pack .lb

  Clicking on the elements in the listbox created echoes the current selection and the active index.  They should be the same, but in successive clicks the active index lags the current selection by 1.  This becomes a serious problem when the "-multiple" option is used on creation of the listbox, so the current selection and the active index are not necessarily the same, but the active index is needed to identify the users's choice and process the event properly.

  Thinking this might be a case of the script being called before all event bindings were processed, I changed the binding using the following command: 

  bind .lb <<ListboxSelect>> "after idle lb_report %W"

  But even after the event queue is empty, the wrong active index is reported in the same way.

  As a workaround I used the following binding:

  bind .lb <<ListboxSelect>> "after 100 lb_report %W"

  This produces the correct active index when the listbox is clicked on.  But doing event programming that depends explicitly on timing is a very poor design choice.

  The Tk FAQ suggests a workaround of binding to a mouse click event and finding the mouse cursor position to deduce the user's choice, but of course this only works if the mouse is used for selection, rather than key presses, which the default bindings enable. 

  ActiveTcl 8.5.8 on Ubuntu Intrepid.


tkt_uuid: 3604758fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: cocoa <Mousewheel> event incorrect %x %y substitutions
comment:
  The cocoa 8.6.0 is returning incorrect %x and %y substitutions.
  It is returning the value relative to the parent of the window, not relative to the window.

  test code:
  grid [label .my -textvariable mousey] -row 1 -column 1
  grid [label .wy -textvariable wheely] -row 1 -column 2
  grid [label .by -textvariable buttony] -row 1 -column 3
  grid [frame .f -width 150 -height 200] -row 2 -column 1 -columnspan 3
  bind .f <Any-MouseWheel> "set wheely %y"
  bind .f <Any-Motion> "set mousey %y"
  bind .f <ButtonPress> "set buttony %y"

  move the mouse in the frame to see the correct %y substitution.
  press the button to see that it is returning the same value.
  move the mouse wheel and see that it's not correct.
  % x substitution has the same problem.


tkt_uuid: 220605ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title:
  slowdown with tcl/tk 8.0.5 and above when creating and destroying windows with large number of widgets in them

comment:
  OriginalBugID: 3220 Bug
  Version: 8.0.5
  SubmitDate: '1999-10-28'
  LastModified: '2000-04-09'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2824 2239 3410 2875
  OS: IRIX
  OSVersion: IRIX64 6.5
  Machine: Other
  FixedDate: '2000-04-09'
  FixedInVersion: 8.3


  Name: Jamie Hecker

  Comments:
  I originally reported this bug as a problem with tclpro1.2, but further
  testing (and help from scriptics) has pointed out that it appears to be
  inherent in all versions of tcl/tk after 8.0.3.  There is a substantial
  difference in speed between 8.0.3 and 8.0.5 and above (I have tried
  8.2.0 and had the same problem).

  ReproducibleScript:
  proc test {} {

      set top [toplevel .toplevel]

      ::wm geometry $top 400x800+600+100

      set canvas [canvas $top.sc -width 400 -height 1000]
      frame $canvas.win -width 100 -height 1000
      $canvas create window 300 25  -window $canvas.win -anchor n

      for {set i 1} {$i <= 200} {incr i} {

      $canvas create text 10 [expr $i * 50]  -text "simple text row $i"  -anchor w

  scale $canvas.win.scale$i -width 5 -label "scale2 $i"  -orient horizontal -length 100

  place $canvas.win.scale$i -in $canvas.win -x 0  -y [expr $i * 50]  -anchor w 

      }

      place $top.sc -x 0 -y 0
      return $top
  }

  for {set i 0} {$i < 100} {incr i} {

      set iteration_time [time "test; update idletasks; destroy .toplevel
  "]

      puts "$i: $iteration_time"

  }

  ObservedBehavior:
  the test case runs approximately 7 times slower after 99 iterations on
  8.0.5.  on 8.0.3 the difference is small (in fact the speed it takes on
  its 99th iteration on 8.0.3 is faster than the first iteration on
  8.0.5).   I have run the test case on Windows NT, and did not see the
  same performance degredation (under 8.0.5), so it appears to be IRIX
  specific

  DesiredBehavior:
  Since the nature of our application requires that widgets be created
  and destroyed very often, I would hope that this operation would have
  little impact on the performance of the application.



  The performance problem is potentially due to TK_USE_INPUT_METHODS,
  which gets defined in tk.h.  Try to #define that out and see if
  the performance problem disappears.  Starting with 8.3, we are
  moving towards getting that #def runtime switchable, with the
  default off. 
  -- 01/07/2000 hobbs
  The related reports all have some similar slowdown seen, relating
  to impaired usage over time or extensive widget creation. 
  -- 01/25/2000 hobbs

  It has been confirmed that moving the XInputMethods code to a
  runtime conditional (tk useinputmethods boolean) has eliminated
  this slowdown for 8.3+.  For earlier versions, make sure to compile
  with the XInputMethods undefined (tk.h).  You can see the effect
  by running Tk8.3 on a previously affected machine with and without
  [tk useinputmethods] set (default off).

  This seems to be an xserver related problem, as not all xservers
  with XInputMethods are affected.  The problem is likely some leak
  in system level resources. 
  -- 04/09/2000 hobbs


tkt_uuid: 3009885fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: None
title: tk_messageBox can return empty string on Windows
comment:
  If the parent window of a tk_messageBox is transient, and the window is iconified, the message box disappears and returns the empty string.

  # Example;
  package require Tk

  tk_messageBox -message test   
  # Iconify the application, the message dialog stay open

  toplevel .t
  tk_messageBox -parent .t -message test
  # Iconify the application, the message dialog stay open

  wm transient .t .
  tk_messageBox -parent .t -message test
  # Iconify the application, the message dialog disappears
  # Deiconify the application, tk_messageBox returns empty string


tkt_uuid: 3295436fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 54. [console]
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: None
title: console doesn't handle <<PasteSelection>>
comment:
  The <<PasteSelection>> event isn't properly handled by console.  It just inserts the text wherever the mouse pointer is, even though this can corrupt the displayed history.  Or, pasting to the "right" location by pointing at the insertion cursor, sometimes fails to put the text into the input buffer.  This handler is inherited from the text widget.

  <<PasteSelection>> is generated by middle-clicking (<ButtonRelease-2>), according to tk.tcl.

  One possible approach is to handle <<PasteSelection>> in the same way as <Insert>, disregarding mouse pointer position.  Another is to attempt to position the insertion cursor to the pointer position but to constrain it to the input line before inserting, the same as clicking and typing.


tkt_uuid: 3592454fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: obsolete: 8.5.13
resolution: None
title: sash for hidden pane still draggable with weird effects
comment:
  As posted on comp.lang.tcl:

  panedwindow .p ; pack .p -expand yes -fill both
  foreach num {1 2 3} { button .$num -text $num }
  .p add .1 .2 .3 -stretch first
  .p paneconf .3 -hide 1

  The sash between buttons 2 and 3 is still one pixel wide. gettign the mouse
  there will show the resize-cursor.  The effect of clicking & dragging it seems
  to depend on the window-manager and on whether the toplevel was manually
  resized by the user.  If the latter, then dragging the sash magically dragged
  the other sash towards the hidden pane. Otherwise it causes the toplevel to
  be resized (but only shrunk, never grown, thus still weird).


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

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

  set encoded_buf [base64::encode $buf]

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


tkt_uuid: 1670123fffffffffffffffffffffffffffffffff
type: Bug
status: Deleted
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Out of Date
title: tkUnixFont.c fails to compile
comment:
  Platform: sparc solaris 9, sun c compiler, compiled
    with options \"'--prefix=/projects/sprs_lwv/tcl85' '--enable-shared' '--enable-symbols' '--enable-stubs' '--enable-64bit' 'CC=cc'\"


  cc -c -g  -xarch=v9   -KPIC -I/vol/tclsrcsol/tcl85/tk/unix/../unix -I/vol/tclsrc
  sol/tcl85/tk/unix/../generic -I/vol/tclsrcsol/tcl85/tk/unix/../bitmaps -I/vol/tc
  lsrcsol/tcl85/tcl/generic -I/vol/tclsrcsol/tcl85/tcl/unix -I/usr/openwin/include
   -DPACKAGE_NAME=\"tk\" -DPACKAGE_TARNAME=\"tk\" -DPACKAGE_VERSION=\"8.5\" -DPACK
  AGE_STRING=\"tk\ 8.5\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPE
  S_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_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DUSE
  _THREAD_ALLOC=1 -D_REENTRANT=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_THREAD_SAFE=1 -DH
  AVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DTCL_THREADS=1 -D_REENTRANT=1 -D_POSIX_PTHREAD_
  SEMANTICS=1 -DTCL_CFG_DO64BIT=1 -DTCL_SHLIB_EXT=\".so\" -DTCL_CFG_DEBUG=1 -DTCL_
  WIDE_INT_IS_LONG=1 -DWORDS_BIGENDIAN=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=
  1 -DHAVE_PW_GECOS=1 -DHAVE_XSS=1      -DTCL_NO_DEPRECATED  -DUSE_TCL_STUBS  /vol
  /tclsrcsol/tcl85/tk/unix/../unix/tkUnixFont.c
  "/vol/tclsrcsol/tcl85/tk/unix/../unix/tkUnixFont.c", line 1409: syntax error before or at: ;
  "/vol/tclsrcsol/tcl85/tk/unix/../unix/tkUnixFont.c", line 1411: warning: undefin
  ed or missing type for: int
  "/vol/tclsrcsol/tcl85/tk/unix/../unix/tkUnixFont.c", line 1414: warning: paramet
  er mismatch: 10 declared, 0 defined
  "/vol/tclsrcsol/tcl85/tk/unix/../unix/tkUnixFont.c", line 1418: undefined symbol
  : rangeLength
  "/vol/tclsrcsol/tcl85/tk/unix/../unix/tkUnixFont.c", line 1418: undefined symbol
  : x
  "/vol/tclsrcsol/tcl85/tk/unix/../unix/tkUnixFont.c", line 1418: undefined symbol
  : y
  cc: acomp failed for /vol/tclsrcsol/tcl85/tk/unix/../unix/tkUnixFont.c
  gmake: *** [tkUnixFont.o] Error 2


  The problem appears to be the semicolons in TkpDrawCharsInContext's argument list...


tkt_uuid: 664790ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 3 Low
foundin: obsolete: 8.4.1
resolution: Fixed
title: SGi warning: TextWidgetCmd
comment:
  cc-1552 cc: WARNING File =
  /home/fs3c/dgp/tk8.4.1/unix/../generic/tkText.c, Line = 621
    The variable "lastEnd" is set but never used.

                  TkTextIndex *indices, *ixStart, *ixEnd,
  *lastStart, *lastEnd;
                                                        
                ^


tkt_uuid: 3603396fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: ttk::sizegrip doesn't use native bindings
comment:
  The bindings on a [ttk::sizegrip] use Tcl procs which resize the window in real time as the mouse is moved. However, on Windows (depending on OS settings) normal behaviour is usually to show a grey bounding box for the window, which resizes on mouse motion, and only resize the window on button release. (Pressing escape while dragging cancels the operation.) It would be nice if this native behaviour could be included in ttk on Windows to get a truly native look and feel.


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: 962104ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: None
title: directory creation button
comment:
  Need to add a directory creation button to
  [tk_getSaveFile] on Unix.

  For more details, see
  http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=c94jat%24em1%2405%241%40news.t-online.com


tkt_uuid: 1347712fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 7 High
foundin: obsolete: 8.5a4
resolution: None
title: tearoff menu title ignored
comment:
  From the menu man page, I can read about the -title 
  option:
  "The string will be used to title the window created when 
  this menu is torn 
  off."

  So running the following snippet:

  menu .m -tearoff 0 -title "Nice menu"
  .m add command -label "hello world"
  .m add command -label [.m cget -title]
  .m clone .m.cl tearoff
  .m.cl post 150 200

  I would expect that the torn-off menu title be "Nice 
  menu".

  I observe that it is "cl", which I believe is a bug.


tkt_uuid: 3602901fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 99. Other
priority: 5 Medium
severity: Minor
foundin: None
resolution: None
title: Documentation of ttk::frame -padding
comment:
  If I believe http://www.tkdocs.com/tutorial/widgets.html, the documentation does not specify that it is possible to use multiple values ​​to determine the padding of a ttk::frame widget.

  I propose to add the following details to ttk_frame.n manpage:

   - a single number specifies the same padding all the way around;
   - a list of two numbers lets you specify the horizontal then the vertical padding;
   - a list of three numbers lets you specify the left, vertical, and right padding, in that order;
   - a list of four numbers lets you specify the left, top, right and bottom padding, in that order.


tkt_uuid: 1217222fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: [.textw edit undo] return ranges of modified characters
comment:
  I would like the text widget command edit undo to return 
  as a result the range(s) of characters in the widget that 
  were modified (impacted) by the undo operation.

  This would allow to apply special processing to these 
  ranges, e.g. colorize these chars, flash them, and so on.

  Same request for redo, of course.

  Thanks,
  Francois


tkt_uuid: 220251ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.2.1
resolution: Invalid
title: binding of <Control-i> does not replace inserting of a tab in text widget
comment:
  OriginalBugID: 3388 Bug
  Version: 8.2.1
  SubmitDate: '1999-11-05'
  LastModified: '1999-11-12'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  ClosedDate: '1999-11-12'


  Name:
  Holger Jakobs

  ReproducibleScript:
  set t [text .t -font $f]
      bind $t <Control-i> {}

  ObservedBehavior:
  Normally, pressing <Control-i> in a text widget inserts a tab character.
      When replacing this
      key binding with something else - or even nothing, for that matter - the
      new binding is accepted
      and will be executed. But subsequently, the inserting of a tab character
      is performed as well,
      although this is no longer wanted.

  DesiredBehavior:
  If replacing or changing a key binding, the standard bindings should not
      be active anymore,
      unless + is used before the bound script.



  As doc'ed in bindtags and bind, the user requires a 'break'
  in the binding. 
  -- 11/12/1999 hobbs


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: 3462273fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6b2
resolution: None
title: Changing image data in ttk does not work
comment:
  Using [$img configure -data $newdata] to change an image already used in a ttk label doesn't change the displayed image.

  The following code show the issue:

  package require Tk
  set icon1 {R0lGODlhEAAQAJEAANnZ2QAAAISEAP///yH5BAEAAAAALAAAAAAQABAAAAJ
      WhI9pFB8RIIRC+BYQFqQQvkWEBSmEbyFhQQrhW0hYkEL4FhIWpBC+hYQFSYxvIgF
      AoXy0AAiSGP8kAIIkxgcICSBEQvEBQgIIkVB8gJAAAhgfj+BjWgEAOw==}
  set icon2 {R0lGODlhEAAQAKIAANnZ2QAAAP///4SEhP//AP///////////yH5BAEAAAA
      ALAAAAAAQABAAAANZCLrcjqG7CLqBoquBoBuCoSqBoBsouhoIuiEYqrKBoIGiqwE
      YEIChyxAIEYGgywEYgKHLDAgRCLozgwABARgIukSEABEBGLq8gAEQCLobgAEAgKH
      LgaDLzZgAOw==}
  set im [image create photo -data $icon1]
  pack [label .l1 -image $im -text Tk -compound left] -padx 100 -pady 50
  pack [ttk::label .l2 -image $im -text ttk -compound left] -padx 100 -pady 50
  set current 1
  proc swapimage {} {
      global current im icon1 icon2
      if {$current == 1} {
         $im configure -data $icon2
         set current 2
      } else {
         $im configure -data $icon1
         set current 1
      }
      after 1000 swapimage
  }
  after 1000 swapimage


tkt_uuid: 219908ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Duplicate
title: Bug when using negative coordinates in window geometry
comment:
  OriginalBugID: 864 Bug
  Version: 8.0.3
  SubmitDate: '1998-11-25'
  LastModified: '1999-08-06'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2326
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-08-06'


  Date: Thu, 5 Nov 1998 07:50:57 -0800 (PST)
  To: tclsupport@scriptics.com
  Subject: Bug when using negative coordinates in window geometry
  From: peter.spjuth@space.se

  Tk 8.0.3 Bug

  email:  peter.spjuth@space.se
  Support:  None
  Severity:  4
  OperatingSystem:  Windows NT
  OperatingSystemVersion:  4.0
  Synopsis:  Bug when using negative coordinates in window geometry

  ReproducibleScript:
  proc change {} {
      global test n
      if {$test == "qwerty"} {set test zxcv} else {set test qwerty}

      incr n
      if {$n < 5} {after 1000 change}
  }

  pack [label .l -textvariable test]
  set test qwerty
  set n 0
  wm geometry . -400-200
  after 1000 change


  ObservedBehavior:
  The window moves over the screen when the label's text changes.


  DesiredBehavior:



  Comments:
  I have tested this with 8.0p2 under Solaris also.
  The effect is the same there, if I run it with "wish scriptfile".
  When I source the script from the wish prompt, the bug does not appear.


tkt_uuid: 3547229fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.5.11
resolution: None
title: Tk crashes when drawing many dashed objects
comment:
  When drawing many dashed lines (problably arcs, ...) wish crashes.
  Problem found on Linux only.
  Error messsage:
  X Error of failed request:  BadValue (integer parameter out of range for operation)
    Major opcode of failed request:  55 (X_CreateGC)
    Value in failed request:  0x0
    Serial number of failed request:  1481
    Current serial number in output stream:  1485

  Attached example:
  Unpack (tar -xzvf view_dxf-8.5-0.3_bugrep.tgz)
    ./view_dxf-8.5-0.3.tk Scheibenkupplunhshaelfte1.dxf

  wish crashes almost all time on Tk 8.5
  wish crashes less often on Tk 8.6 (try reloading by double click icon "*" entry in the listbox if no crash)  
  effect not found on Tk 8.4 or Windows
  example requires BWidget.


tkt_uuid: 540238ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: -- New Stub Entries
priority: 5 Medium
foundin: None
resolution: Out of Date
title: TkWin*DrawableDC
comment:
  >From "Lothar Linhard" <lothar@concept.de>


  Make TkWinGetDrawableDC and TkWinReleaseDrawableDC
  available to extensions.


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

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

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


tkt_uuid: 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: 2980135fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 28. Utility Functions
priority: 5 Medium
foundin: None
resolution: None
title: TkBackgroundEvalObjv - support return options
comment:
  TBEO() saves and restores interp state using
  old patterns.  Should be updated to use 
  Tcl_Save|RestoreInterpState() so that return
  options beyond -errorinfo and -errorcode get
  proper treatment.


tkt_uuid: 220837ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: final: 8.0.5
resolution: Duplicate
title: keypad 4 does not generates "left" keysym
comment:
  OriginalBugID: 1810 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-14'
  LastModified: '2000-02-10'
  Severity: SER
  Status: UnAssn
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 2680
  OS: Solaris
  Machine: Other


  Name:
  Robert S Lee

  Comments:
  Displaying on SunOS4.x and NT 4 running Exceed 6, I get the correct
      behavior with cursor keys (2,4,6,8) on the keypad with numlock on. 
      However, displaying on Linux Redhat 5.2 and Solaris 2.6, the cursors
      keys don't work correctly.
      
      On Solaris 2.6 and Redhat5.2, the number 4 on keypad with NumLock turned
      on does not generate 4, but "Left" keysym.  On Exceed 6 and SunOS 4.x,
      the number 4 on keypad with NumLock turned on does generate "KP_4"
      keysym which is correct.
      
      -----------------------------------------
      
      The "xev" program on all 4 systems report that the number 4 on keypad
      with NumLock turned on generate KP_4, as shown below (output from
      Solaris 2.6).  The following is xev is generated with left cursor key,
      key pad number 4 with numlock off, then key pad number 4 with num lock
      on.
      
      KeyRelease event, serial 22, synthetic NO, window 0x9400001,
          root 0x2a, subw 0x9400002, time 682981314, (34,31), root:(346,55),
          state 0x20, keycode 31 (keysym 0xff51, Left), same_screen YES,
          XLookupString gives 0 characters:  ""
      
      KeyRelease event, serial 22, synthetic NO, window 0x9400001,
          root 0x2a, subw 0x9400002, time 682987873, (34,31), root:(346,55),
          state 0x0, keycode 98 (keysym 0xff51, Left), same_screen YES,
          XLookupString gives 0 characters:  ""
      
      KeyRelease event, serial 22, synthetic NO, window 0x9400001,
          root 0x2a, subw 0x9400002, time 682976014, (34,31), root:(346,55),
          state 0x20, keycode 98 (keysym 0xffb4, KP_4), same_screen YES,
          XLookupString gives 1 characters:  "4"
      
      The Tcl/Tk app output with the same sequence of keys.
      
      $ ./simple.tcl
       {W=.ent1 #=185 A={}  x=63 y=8 b=31 s=0 K=Left} 
       {W=.ent1 #=233 A={}  x=63 y=8 b=98 s=0 K=Left} 
       {W=.ent1 #=252 A={}  x=63 y=8 b=105 s=0 K=Num_Lock} 
       {W=.ent1 #=366 A=4  x=63 y=8 b=98 s=32 K=Left} 
      
      -----------------------------------------
      
      The "xev" program on Exceed, which works correctly, generates KP_4, but
      note that keycodes are different.
      
      KeyRelease event, serial 21, synthetic NO, window 0x5c00001,
          root 0x29, subw 0x5c00002, time 3070847, (47,32), root:(875,319),
          state 0x0, keycode 101 (keysym 0xff51, Left), same_screen YES,
          XLookupString gives 0 characters:  ""
      
      KeyRelease event, serial 21, synthetic NO, window 0x5c00001,
          root 0x29, subw 0x5c00002, time 3072019, (47,32), root:(875,319),
          state 0x0, keycode 82 (keysym 0xff51, Left), same_screen YES,
          XLookupString gives 0 characters:  ""
      
      KeyRelease event, serial 21, synthetic NO, window 0x5c00001,
          root 0x29, subw 0x5c00002, time 3073301, (47,32), root:(875,319),
          state 0x0, keycode 112 (keysym 0xffb4, KP_4), same_screen YES,
          XLookupString gives 1 characters:  "4"
      
      The Tcl/Tk app output with the same sequence of keys.
      
      $ ./simple.tcl
       {W=.ent1 #=191 A={}  x=34 y=11 b=101 s=0 K=Left} 
       {W=.ent1 #=242 A={}  x=34 y=11 b=82 s=0 K=Left} 
       {W=.ent1 #=289 A=4  x=34 y=11 b=112 s=0 K=KP_4} 
      
      Note the last entry of the "simple.tcl" output.  The K, which is keysym,
      is reported as KP_4 when it works, but reported as "Left" when it does
      not work.  In addition, when the "simple.tcl" works, the "keycodes" as
      reported by xev are different for all three combination of keys.
      
      So the questions are as follows:
      
      1.  For left key, keypad 4 with numlock off, and keypad 4 with numlock
      on:
      
              should different keycode be generated for all three keys?
      
      2.  For Tcl/Tk, why does it think keysym is "Left" when xev is reporting
      "KP_4".
      
      Any help will be appreciated.

  ReproducibleScript:
  With the numlock on, press keypad 4.  On systems that works, we get "4"
      in the field.  In the systems that does not work, we get "left" cursor
      key behaviro.
      
      #!/usr/local/bin/wish -f
      
      label .lab1 -text "Name:"
      entry .ent1
      bind .ent1 <KeyPress> "puts \" {W=%W #=%# A=%A  x=%x y=%y b=%b s=%s
      K=%K} \""
      grid .lab1 -row 1 -column 0 -sticky e
      grid .ent1 -row 1 -column 1 -sticky ew



  2680 has a script to show the behavior. 
  -- 02/10/2000 hobbs


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: 3601604fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 09. [listbox]
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: [listbox $path -takefocus 0] steals focus
comment:
  The listbox manpage says it will take focus on <1> if the widget -state is normal and -takefocus is 1. However, it always takes focus, regardless of the -takefocus option.

  The binding for <1> on Listbox should be something like

    bind Listbox <1> {    if {[winfo exists %W]} { tk::ListboxBeginSelect %W [%W index @%x,%y] [string is true [%W cget -takefocus]] }}

  (Currently, where I have [string is true [%W cget -takefocus]] it just has 1.)


tkt_uuid: 220691ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: Images appear stippled in menubuttons
comment:
  OriginalBugID: 4246 Bug
  Version: 8.2
  SubmitDate: '2000-02-25'
  LastModified: '2000-02-28'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  Machine: SunOS bksmx1 5.6 Generic_105181-16 sun4u sparc SUNW,UltraAX-MP
  FixedDate: '2000-02-28'
  FixedInVersion: 8.3b2


  Name:
  Tom Allard

  Extensions:
  None.

  CustomShell:
  None.  Uses prowish82 as distributed with TclPro 1.3.

  ReproducibleScript:
  # Assumes you have any xbm file called file.xbm in current directory
  prowish82
  catch "image create bitmap -file file.xbm" NewImage
  button .x -image $NewImage
  pack .x
  menubutton .y -image  $NewImage
  pack .y

  ObservedBehavior:
  When run with wish8.0, both images appear identical.  With prowish82, the second image appears stippled.  The second image should only be stippled if the menubutton state is disabled, which it is not in this example.

  DesiredBehavior:
  I do not expect to see the image in .y stippled (unless I change its state).



  Already fixed for 8.3 release. 
  -- 02/28/2000 hobbs


tkt_uuid: 1155661fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: None
resolution: None
title: Menu height option.
comment:
  Currently if you have to many menu items to display on 
  the screen, the inner workings of the menu command 
  places arrow(scroll) buttons at the top and the bottom of 
  the menu list.

  It would be nice to have an option to tell the menu 
  command how many items you display on the screen 
  (similar to the listbox -height option) and if you have 
  more items in your menu, than in this option, to display 
  the arrow(scroll) buttons.


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: 1082213fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: None
title: word wrapping should trim excess spaces
comment:
  pack [text .t -width 12 -height 5 -wrap word -font fixed]
  .t insert end "this is not       what is       normally
  called       word wrapping"

  Would under most norms of word-wrapping produce lines
  all left aligned.  However the text widget instead
  wraps in the middle of a group of spaces and therefore
  starts some lines with empty spaces.

  See e.g. 

  http://groups-beta.google.com/group/comp.lang.tcl/browse_thread/thread/a00b6e2a2c07086a


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

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

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

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


tkt_uuid: 220160ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 1 Zero
foundin: final: 8.0.5
resolution: Invalid
title: entry is not properly updated when textvariable is changed
comment:
  OriginalBugID: 1787 Bug
  Version: 8.0.5
  SubmitDate: '1999-04-12'
  LastModified: '1999-08-13'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Linux
  OSVersion: latest slackware i586
  Machine: Other
  ClosedDate: '1999-08-13'


  Name:
  Luc Deschenaux

  Comments:
  one more :)

  ReproducibleScript:
  when I bind <Button-1> to a listbox so that I an reflect the current
      selection in the entry it doesnt works.. with <Double-1> it works..
         
         global newname
         $w.entry#1 configure -textvariable newname
         bind $w.listbox#1 <Button-1> {
          global newname
          set l .pname.listbox#1
          set csel [$l curselection]
          if {$csel!={}} {
            set newname [$l get [lindex $csel 0]]
            update idletasks
          }
        }

  ObservedBehavior:
  it works with <Double-1> but the entry is updated with a one-click delay
      when using <Button-1>

  DesiredBehavior:
  I'll use <Double-1> but it should work with <Button-1>



  This is a programming error.  The user should refer to the
  Tk Usage FAQ on listboxes for the various solutions:
      http://www.purl.org/net/hobbs/tcl/faqs/tk/ 
  -- 08/13/1999 hobbs


tkt_uuid: 3613668fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 67. Unix Window Operations
priority: 9 Immediate
severity: Minor
foundin: current: 8.6.0
resolution: None
title: XFilterEvent() hangs
comment:
  Starting with checkin

  http://core.tcl.tk/tk/info/2a535c6792

  we've started calling XInitThreads() as part of
  opening the first display in a process, which is
  meant to improve multi-threaded access to
  the X server.

  However, since then, the first call to XFilterEvent()
  in tclUnixEvent.c that has a Window argument with
  a value other than None will hang up the application
  hard.  It becomes non-responsive, and has to be
  killed.  Apparently a deadlock inside the Xlib brings
  things to a halt.

  Typically this is the first key press in the application
  that triggers the hang.


tkt_uuid: 232731ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 6
resolution: Out of Date
title: exec grabs stdin -- wish8x.exe on Win9x only
comment:
  Problem summary:
    The exec command can be used to run a command in a shell [console] window on every platform except Win-95/98 (-ME?).  On Unix this is done with 
  exec xterm -e /bin/sh -c ...
  on Win-NT this is done with 
  exec $env(COMSPEC) /c "start ..."
  On Win-95/98 (I have not tried -ME) if one tries this, the DOS window the keyboard is not connected to stdin. This is not a Windows limitation, but rather a problem in wish (I have tested 8.0.3, 8.2.3 and 8.4a2).

  Example: 
    create a batch file, C:\test\test.bat, that contains three commands:
   
         PAUSE
         DIR
         PAUSE
   
  try to run this file from wish8x.exe using (for example)
  exec start {c:\test\test.bat} &
  the DOS box is created and you see the prompt "Press any key to continue..." but the window is hung. Note this does work from tclsh.exe.

  Details:
    This appears to be a problem with the exec command rather than an inherent limitation in Windows, because it is possible to achieve the correct result using the WINEXEC package (http://www.du.edu/~mschwart/tclextensions.html#WinexecTbl). The winexec command uses a direct call to CreateProcess 
  result = CreateProcess (argv[1],  0,  0, 0, 0, DETACHED_PROCESS, 0, 
  options.dirnameptr,  &si, &pi);
  so the problem must be related to all of the extra stuff that the exec command does.

  It would be good to have this limitation eliminated from wish on the Win-9x platform, rather than require use of a binary package and a non-standard command to achieve equivalence with wish on Unix and Win-NT.

  Brian


tkt_uuid: 671330ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 9 Immediate
foundin: obsolete: 8.4.1
resolution: Fixed
title: segfault when e.g. deiconifying destroyed window
comment:
  (at least that's what it looks to me)
  I have a (quite long) script that does on toplevel on
  the local screen and on on a remote screen. If there
  are more top-levels on the remote screen (sometimes
  requires user interaction) I do raise & deiconify the
  toplevel on <Visibility> and <Unmap> event (just in
  case the operator tries to close the window). In case
  more toplevels are fighting for the topmost postion, I
  do the raising with a (random) delay of ~2000 ms.
  Sometimes I do get segfaults, when, so far I have
  debugged the thing, I do deiconify the window. I thing
  (but I'm not sure) this is when I binded an empty
  script to the two events, destroyed the toplevel and
  the random delay is still running and fireing the
  deiconify/raise later. (Well, that might not be a good
  way to code, but that's another story). It could as
  well be, that X on on of the 2 screens terminates, I
  just don't know.

  You can check the thread "suggestion to track down
  segfaults"
  at Google
  http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&safe=off&threadm=3E2814AC.9070107%40inode.at&prev=/groups%3Fdq%3D%26num%3D30%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.tcl%26safe%3Doff%26start%3D30

  Everything (code exaples and stack traces are listed there)

  I've spent quit a lot hours trying to set up a x-liner
  to reproduce the error, but I was'nt successful. Sorry.
  If you want me to do some more debugging, give me a
  note (and a list of gdb commands ;-) )

  Gerhard


tkt_uuid: 605121ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 8
foundin: obsolete: 8.4.0
resolution: Fixed
title: segfault in entry var trace / ns delete
comment:
  Reported by Ramon Ribó on CLT:

  interp create local
  local eval { set argc 0 ; set argv "" }
  local eval source notebook.tcl
  interp delete local

  where notebook is the nice Notebook App in
  http://mini.net/cgi-bin/wikit/3712

  (needs BWidgets and other packages installed)

  Stack trace:

  Crash because TclLookupVar is being passed NULL for part1.

  #0  0x1201c8394 in TclLookupVar (interp=0x12043b620,
  part1=0x0, part2=0x0, 
      flags=1, msg=0x120216be7 "set", createPart1=1,
  createPart2=1, 
      arrayPtrPtr=0x11fffe5c0) at ./../generic/tclVar.c:236
  #1  0x1201ca084 in Tcl_SetVar2Ex (interp=0x12043b620,
  part1=0x0, part2=0x0, 
      newValuePtr=0x12051bac0, flags=1) at
  ./../generic/tclVar.c:1430
  #2  0x1201c9f80 in Tcl_SetVar2 (interp=0x12043b620,
  part1=0x0, part2=0x0, 
      newValue=0x1205ba810 "", flags=1) at
  ./../generic/tclVar.c:1367
  #3  0x1201c9ecc in Tcl_SetVar (interp=0x12043b620,
  varName=0x0, 
      newValue=0x1205ba810 "", flags=1) at
  ./../generic/tclVar.c:1311
  #4  0x1200392cc in EntryTextVarProc
  (clientData=0x1205ba5c0, 
      interp=0x12043b620, name1=0x1205312c0 "", 
      name2=0x12054ad40 ".pb-searchtext", flags=192)
      at /local/src/tk/unix/../generic/tkEntry.c:3305
  #5  0x1201ceef8 in CallVarTraces (iPtr=0x12043b620,
  arrayPtr=0x0, 
      varPtr=0x12054ad60, part1=0x1205312c0 "", 
      part2=0x12054ad40 ".pb-searchtext", flags=192,
  leaveErrMsg=0)
      at ./../generic/tclVar.c:4188
  #6  0x1201cff40 in DeleteArray (iPtr=0x12043b620,
  arrayName=0x1205312c0 "", 
      varPtr=0x120576df0, flags=64) at
  ./../generic/tclVar.c:4769
  #7  0x1201cf8b0 in TclDeleteVars (iPtr=0x12043b620,
  tablePtr=0x120589ac8)
      at ./../generic/tclVar.c:4573
  #8  0x12019ede8 in TclTeardownNamespace (nsPtr=0x1205899d0)
      at ./../generic/tclNamesp.c:761
  #9  0x12019eb04 in Tcl_DeleteNamespace
  (namespacePtr=0x1205899d0)
      at ./../generic/tclNamesp.c:640
  #10 0x12019eea0 in TclTeardownNamespace (nsPtr=0x1204df7a0)
      at ./../generic/tclNamesp.c:791
  #11 0x12019eb04 in Tcl_DeleteNamespace
  (namespacePtr=0x1204df7a0)
      at ./../generic/tclNamesp.c:640
  #12 0x12019eea0 in TclTeardownNamespace (nsPtr=0x12043b920)
      at ./../generic/tclNamesp.c:791
  #13 0x120119e14 in DeleteInterpProc (interp=0x12043b620)
      at ./../generic/tclBasic.c:990
  #14 0x1201b3504 in Tcl_EventuallyFree
  (clientData=0x12043b620, 
      freeProc=0x120119d80 <DeleteInterpProc>) at
  ./../generic/tclPreserve.c:313
  #15 0x120119d60 in Tcl_DeleteInterp (interp=0x12043b620)
      at ./../generic/tclBasic.c:927
  #16 0x12017e7d0 in SlaveObjCmdDeleteProc
  (clientData=0x12043b620)
      at ./../generic/tclInterp.c:2031
  #17 0x12011be5c in Tcl_DeleteCommandFromToken
  (interp=0x1203462f0, 
      cmd=0x1203d8bc0) at ./../generic/tclBasic.c:2447
  #18 0x12017b544 in Tcl_InterpObjCmd (clientData=0x0,
  interp=0x1203462f0, 
      objc=3, objv=0x11ffff080) at
  ./../generic/tclInterp.c:511
  #19 0x12011cf3c in TclEvalObjvInternal
  (interp=0x1203462f0, objc=3, 
      objv=0x11ffff080, command=0x12043b5d4 "interp
  delete local\n", length=20, 
      flags=0) at ./../generic/tclBasic.c:3033
  #20 0x12011e05c in Tcl_EvalEx (interp=0x1203462f0, 
      script=0x12043aef0 "interp create local\nlocal eval
  [list set argc 0]\nlocal eval [list set argv {}]\nlocal
  eval {\nset notebookVersion \"V0.9\"\npackage require
  Tk\nset appdir [file dirname [info script]]\nlappend
  auto_path [fil"..., 
      numBytes=1784, flags=0) at ./../generic/tclBasic.c:3631
  #21 0x120191608 in Tcl_FSEvalFile (interp=0x1203462f0,
  pathPtr=0x1203b76b0)
      at ./../generic/tclIOUtil.c:1371
  #22 0x120190288 in Tcl_EvalFile (interp=0x1203462f0, 
      fileName=0x11ffff3e8 "crash.tcl") at
  ./../generic/tclIOUtil.c:234
  #23 0x12001b348 in Tk_MainEx (argc=1, argv=0x11ffff550, 
      appInitProc=0x12001ae80 <Tcl_AppInit>,
  interp=0x1203462f0)
      at /local/src/tk/unix/../generic/tkMain.c:234
  #24 0x12001ae58 in main (argc=2, argv=0x11ffff548)
      at /local/src/tk/unix/tkAppInit.c:68


tkt_uuid: 682603ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: Works For Me
title: canvas arc and rect broken on alpha
comment:
  Forwarded bug reports from Debian.  Original reports
  can be seen at <http://bugs.debian.org/151435> and
  <http://bugs.debian.org/156702>.  Basically, "create
  rect" (with reasonable coordinates) and "create arc"
  both fail on Alpha (64-bit architecture).  I suspect
  that they will also fail on other 64-bit archs (like
  ia64), will confirm/deny this last as soon as possible.


tkt_uuid: 230562ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: Fixed
title: Mistranslation in tk/library/msgs/de.msg
comment:
  "File names:" is translated with "Nombre de archivos:"
  whereas it should be "Dateinamen:"

  There are two more typesetting mistakes in the file.
  I put a unified diff under 

  http://mathematik.htwm.de/tmp/tcltk/msgs.diff


tkt_uuid: 734361ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 5 Medium
foundin: None
resolution: Duplicate
title: crash in PolygonToPostscript with 2 identical points
comment:
  Forwarded bug report from Debian Project, submitted
  (with patch) by  Andreas Wilm
  <wilm@rubin.biophys.uni-duesseldorf.de> (for original
  report, see http://bugs.debian.org/192302):

  "Create a polygon with two identical points and no
  outline color (I know this seems to be nonsense, but in
  my case it was absolutely needed). Do a postscript
  command on the canvas and you get the core dump (a
  color NULL pointer is passed on from
  PolygonToPostscript to Tk_PostscriptColor, where it is
  referenced)."

  To reproduce:

  % canvas .c
  % pack .c
  % .c create polygon 10 20 10 20
  % .c postscript

  Debian maintainer comments: I can reproduce the crash
  on 8.3.5 and 8.4.2. I haven't tested the patch, but it
  looks straightforward enough.  The scenario may seem
  odd, but it's the kind of thing that could easily arise
  programatically, i,.e., graphing some data that
  includes some degenerate cases.  Arguably a minor
  problem, but it should not segfault!


tkt_uuid: 220928ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Out of Date
title: tk_popup locks up BWidget notebook
comment:
  OriginalBugID: 5899 Bug
  Version: 8.3
  SubmitDate: '2000-06-14'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: All Windows
  OSVersion: Windows 98, Windows NT 4 SP3


  Name:
  Stefan Koch

  Extensions:
  BWidget, Tk

  ReproducibleScript:
  ########################################################################
  #
  #   File:       Example code tk_popup lock up problem of Bwidget notebook
  #
  #
  #   Required:   tcl/tk8.3, BWidget
  #
  #   Created:    15.06.2000 - SCENTECH AG sk
  #
  #   EMAIL: stefan.koch@scentech.ch 
  #   URL:   http://www.scentech.ch
  #
  ########################################################################
  #
  # Description
  #############
  #
  # 1. Start Script
  # 2. Click on button of notebook page 1
  # 3. Open mouse menu and select "close"
  # 4. Check if notebook pages can be selected
  #
  # Observed behaviour
  ####################
  #
  # -open the popup menu will lock up the notebook page (happens every second time)
  # -lock up happens only if grab is used
  # -invoking any other popup menu will resolve the lock up (not implemented in this example)
  # -clicking on the window frame ".appl" will allow a selection once
  #
  ####################
  # MAIN
  ####################
  package require BWidget

  # dispose .
  wm withdraw .

  # create new toplevel
  toplevel .appl

  # create and pack bwidget notebook
  set notebook [NoteBook .appl.nb]
  pack $notebook -fill both -expand true

  # create page 1 
  ##################
  set p1 [$notebook insert end page1 -text "Page 1"]
  # create frame for page content
  set p1f [TitleFrame $p1.f -text "Page 1"]
  # add a button
  set butt [button [$p1.f getframe].butt -text "Click here to open new toplevel"  -command {do_it}]
  # and pack
  pack $butt
  pack $p1f -fill both

  # create page 2
  ###################
  set p2 [$notebook insert end page2 -text "Page 2"]
  # create frame for page content
  set p2f [TitleFrame $p2.f -text "Page 2"]
  # add a label
  set lab [label [$p2.f getframe].lab -text "some dummie text"]
  # and pack
  pack $lab
  pack $p2f -fill both

  # raise first page
  $notebook raise page1

  # cleanup when exit
  wm protocol .appl WM_DELETE_WINDOW "exit"

  ####################
  # END MAIN
  ####################

  # proc to create toplevel window
  # with grab and a popup
  ####################
  proc do_it {} {

      # create a toplevel with some label text
      toplevel .appl.something
      set lab [label .appl.something.lab  -text "Click on right mouse button to activate the popup
  use the close menu to close this window 
  and then try to select a new page within the notebook

  Observation:
  ============
  notebook pages can only be selected properly every 
  second time the tk_popup is invoked"]
      pack $lab

      bind $lab <3> {call_popup %X %Y}

      # set the grab to our new toplevel
      grab set .appl.something
  }

  # proc to create a popup menu
  ####################
  proc call_popup {rootx rooty} {

      set m .appl.popup

      # create popup
      catch {destroy $m}
      menu $m -tearoff false
      $m add command -label "close"   -command "call_close"

      tk_popup $m $rootx $rooty
  }

  # proc to close and release grab
  ####################
  proc call_close {} {

      # release grab
      grab release .appl.something
      # destroy toplevel
      destroy .appl.something
  }

  ObservedBehavior:
  # Observed behaviour
  ####################
  #
  # -open the popup menu will lock up the notebook page (happens every second time)
  # -lock up happens only if grab is used
  # -invoking any other popup menu will resolve the lock up (not implemented in this example)
  # -clicking on the window frame ".appl" will allow a selection once

  DesiredBehavior:
  no lock up


tkt_uuid: 684070ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Encoding problems (no Unicode)
comment:
  I don't know if this is a bug not noticed before,
  or simply something which is because things haven't
  been implemented yet, but the fact remains: The Tk
  widgets don't display the characters that they are
  told to. A note on http://mini.net/tcl/3753 
  (encoding problems are listed as "solved") seems to 
  claim that all this has been fixed as of 8.4.1, but
  the below indicates that they are not.

  Consider the sequence of commands:

  () % info patchlevel
  8.4.1
  () % label .a -text "Hello world!"
  .a
  () % pack .a -padx 10 -pady 10

  Now we're at picture A in the attached archive.
  So far, everything is OK, but now let's try it with
  a non-ASCII character.

  () % .a configure -text "Hello \u01F5world!"

  This changes the window to what it shown in picture B.
  Clearly, the expected U+01F5 (LATIN SMALL LETTER G WITH
  ACUTE) is missing in the label text. Of course, this 
  could be because it is missing from the font, so let's
  check that.

  () 7 % .a cget -font
  system
  () 8 % font actual system
  -family {Lucida Grande} -size 13 -weight normal -slant roman -
  underline 0 -overstrike 0

  Hence the font is Lucida Grande. Switching to the 
  character palette (which BTW does not seem to want to 
  show when Wish is the active program), we see what is
  in picture C: This character _is_ included in Lucida
  Grande. Hence it is not the font that is to blame.

  Most of the characters in the ISO latin 1 range work
  all right, but a few produce very strange results.
  Consider

  () % .a configure -text "Hello \xa4world!"

  --the result of which can be seen in picture D.
  That doesn't like the expected international currency
  sign to me, but rather like some CJK ideograph.


tkt_uuid: 641778ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: SEGV on "see"
comment:
  I am not a tcl programmer, I use Python/Tkinter, so here 
  is the bug I originally posted on the Python bugs list:

  [ 641215 ] Fascinating Text.see() SEGV

  OS: GNU/Linux 2.4.16, Debian 3.0
  Python:
  2.1.3 (#1, Apr 20 2002, 10:14:34)
  [GCC 2.95.4 20011002 (Debian prerelease)] on linux2
  After my large Python/Tkinter application did a SEGV, I 
  chopped out code till I was left with this little beauty:
  #!/usr/bin/python
  # An interesting bug in the Tk Text widget
  #
  # To find where the bug is, go:
  #  gdb python
  #  (gdb) run textsee.py
  # The output I get is:
  #  Program received signal SIGSEGV, Segmentation fault.
  #  [Switching to Thread 1024 (LWP 13789)]
  #  0x403162ce in TkTextSeeCmd () from 
  /usr/lib/libtk8.3.so.1
  from Tkinter import *
  root = Tk()
  # If this font is any bigger, it's OK
  # If this bd is any smaller, it's OK
  t = Text(root, font=("Helvetica", 8, "normal"), bd=16)
  # Packing actually makes no difference
  t.pack()
  # If this string is any shorter, it's OK
  t.insert(END, "Hello")
  # This see() method SEGVs
  t.see(END)
  # We never get here
  root.mainloop()
  # EOF
  It does the same under python1.5.2 (#0, Jan 12 2002, 
  11:51:45)  [GCC 2.95.4 20011006 (Debian prerelease)] 
  on linux2.
  I have not tried it under windows
  I'm not a tcl programmer, so have not tested using tcl.
  Pythonically yours.



  Date: 2002-11-20 14:10
  Sender: grahamh
  Actually, packing does make all the difference, if you call
  update() or update_idletasks on the text widget or root 
  (or any widget, even one that is not 
  packed|placed|gridded). So, the bug seems to be: calling 
  see() on a Text widget (I have not tested others) that is 
  not visible yet does a SEGV.



  Date: 2002-11-20 22:51
  Sender: nnorwitz
  Logged In: YES
  user_id=33168
  I'm closing this bug, since it is definitely Tk.  Here's the
  tcl code which crashes:
  $ wish
  % text .t -font { Helvetica 8 normal } -bd 16 .t
  % .t insert end Hello
  % .t see end
  Segmentation fault (core dumped)

  I'm running Tcl/Tk 8.3.3 on Redhat Linux 7.2.  Please file 
  a bug report with Tcl/Tk.  I think they can be found at:
  http://sf.net/projects/tcltk



  So there it is, but note that it only crashes at certain font 
  and border sizes (wierd!).

  Sorry I cannot provide a patch, it's over to you guys :-)


tkt_uuid: 879073ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Provide expected tab stop behavior
comment:
  This patch file is for Tk8.4.2.  It modifies
  generic/tkTextDisp.c.

  The problem is that the text widget has unusual tabbing
  behavior that doesn't match the expectations of users.
   The patch changes the tab stop behavior to match most
  user's expectations.

  Here is an example that demonstrates the strange
  behavior (note that '\t' means hit the Tab key, and
  '\n\ means hit the Enter or Return key):

  In "wish" create the text widget using:

  text .t -width 40 -height 20 -font {"Courier" 10} -tabs
  {30 left 60 90 120 150}
  pack .t

  Then set the focus on the text widget and type
  "\tx\tx\tx\tx\nxxxxx\tx\txx\tx\tx".  In the unpatched
  code you will see:
                                                        
                           
  bbbbxbbxbbxbbx
  xxxxxbxbxxbxbx

  As you can see (adjusting for proportional font
  distortions), the tabs are not moving the insertion
  point to the expected tab stops.

  After applying the patch, typing that same string yielded:

  bbbbxbbxbbxbbx
  xxxxxbxbbxxbxbbx

  This time, the tab stops are honored and the insertion
  points are where we expect them to be.

  NOTE: I did not invent this patch.  While search for a
  solution to the problem I found this patch given at
  this webpage:

  http://www.qs.co.nz/Tcl/TkTabs.html

  --
  Dave Hein


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

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


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

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

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

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

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

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


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


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

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

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


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

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

  See

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

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

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

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


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

  It works in the following way:

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

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

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

  All this is only relevant on Unix.

  For more inforamation, see:

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

  The patch is against 8.4a3cvs.


tkt_uuid: 3033786fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 3 Low
foundin: None
resolution: Wont Fix
title: Cannot embed Tk in a Cocoa Application
comment:
  Tk built against Cocoa does not allow Tk to be embedded in another Cocoa application.  This is apparent when embedding Python inside of a Cocoa application.  The tkinter module does not work.

  I think the problem stems from the fact that the Tk initialization code subclasses NSApplication.  If another application gets a chance to create an NSApplication object errors like this are thrown:

  2010-07-23 15:30:59.721 X-Chat Aqua[32706:903] -[SGApplication _setup:]: unrecognized selector sent to instance 0x606aa0
  2010-07-23 15:30:59.722 X-Chat Aqua[32706:903] Exception raised during posting of notification.  Ignored.  exception: \'-[SGApplication _setup:]: unrecognized selector sent to 

  See the attached example to reproduce the problem (requires Xcode).

  I\'ve found at least two applications that use Python scripting on the Mac that are broken with respect to being able to use Tk.  Our application works on 10.5 (since Tk there is built against Carbon).

  http://golly.sourceforge.net/
  https://sourceforge.net/projects/xchataqua/

  These are both open source applications, but any application that uses Python scripting is probably broken (see http://wiki.python.org/moin/AppsWithPythonScripting).


tkt_uuid: 226652ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: Fixed
title: TK does not handle IME input on English Win2K
comment:
  Win2K now has "multi-lingual" support: e.g., it allows you to input Chinese characters on an English version of win2k. See the following link for details.

  http://www.microsoft.com/windows/ie/features/w2kime.asp

  Tk 8.4a2 and before do not handle this type of situation. If you use English win2k and try to input a Chinese char into a TK window, the char shows up as "?"

  The fix is to handle WM_INPUTLANGCHANGE and WM_IME_COMPOSITION events. I have a fix and I will submit to the SF patch manager shortly.

  After the fix, you can enter chars of any language, as long as the Input Method Editor of the given language is installed on your win2k box.

  The fix is for win2k only, but it's harmless on other versions of windows (95/98 or NT).


tkt_uuid: 220841ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: Fixed
title: Synchronisation between Tcl and Tk events
comment:
  OriginalBugID: 2074 RFE
  Version: 8.1
  SubmitDate: '1999-05-14'
  LastModified: '1999-11-16'
  Severity: MED
  Status: UnAssn
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 1525
  OS: Linux
  OSVersion: 4.2
  Machine: Other


  Name:

  Jan Nijtmans



  DesiredBehavior:

  This patch only works in combination with Request 1525 for Tcl

      See also:

      

      http://www.scriptics.com/live/showurl?i=software%2epatches%2etcl81b2&url=

      %2fpatches%2ftcl8%2e1b2%2ftcl%2edecls%2e1525%2etxt

      

      This earlier request provides a dummy event loop for Tcl. The patch

      below

      modifies Tk such that the Stub pointer to Tcl_MainLoop() is modified to

      point to Tk_MainLoop(). The netto effect of both those patches is that

      when libtk8.1.so is dynamically loaded into tclsh at initialization

      time, Tk_MainLoop is started. Thereby tclsh starts to behave exactly the

      same as wish.



  Patch:

  *** generic/tkWindow.c.origThu Apr 29 21:38:01 1999

  --- generic/tkWindow.cFri May 14 20:06:54 1999

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

  *** 2718,2723 ****

  --- 2718,2725 ----

            return TCL_ERROR;

        }

    

  +     Tcl_MainLoop = Tk_MainLoop;

  + 

        tsdPtr = (ThreadSpecificData *) 

    Tcl_GetThreadData(&dataKey, sizeof(ThreadSpecificData));



  PatchFiles:

  tkWindow.c


tkt_uuid: 406317ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 27. Objects
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: Fixed
title: MM type can lack string rep
comment:
  The code described at
  http://mini.net/cgi-bin/wikit/1329.html does not work
  with the CVS HEAD version of Tk, but rather panics with
  a complaint about how "UpdateStringProc should not be
  invoked for type mm".  A work-around is to force a
  particular variable to have a string representation,
  but this is not good in any case.  Instead, the problem
  should not occur in the first place.

  Suggested fix: write an updateStringProc for the MM
  type.


tkt_uuid: 220833ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.0.4
resolution: None
title: Suggestions for out-of-box compile on DYNIX/ptx
comment:
  OriginalBugID: 1716 RFE
  Version: 8.0.4
  SubmitDate: '1999-04-05'
  LastModified: '2000-02-08'
  Severity: LOW
  Status: UnAssn
  Submitter: pat
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA


  I am forwarding this to you after the message bounced to the address given
  in the README of the package I have.  I am adding some additional
  information the Don Libes requested:

  Tcl version 8.0
  Expect version 5.28

  % grep host config.status
  # on host sweep:
  s%@host@%i386-sequent-sysv4%g
  s%@host_alias@%i386-sequent-sysv4%g
  s%@host_cpu@%i386%g
  s%@host_vendor@%sequent%g
  s%@host_os@%sysv4%g

  Please let me know if there is any other information you require.

  Regards,

  Mike.

  >Date: Tue, 02 Feb 1999 16:28:52 -0500
  >To: john.ousterhout@eng.sun.com, libes@nist.gov
  >From: Michael Kuhl <mkuhl@legato.com>
  >Subject: Suggestions for out-of-box compile on DYNIX/ptx
  >
  >Gentlemen,
  >
  >I have managed to get both tcl and expect to compile on a Sequent NUMA-Q 
  >machine running DYNIX/ptx v4.4.2.  Neither package compiled straight out f 
  >the box, and I wanted to pass on as much information as I could in orderto 
  >help you possibly put support into your packages in the future for this 
  >platform.
  >
  >Forgive me, as I am not knowledgeable about this platform, and am also not 
  >knowledgeable about the details of building/compiling processes.  I know 
  >enough to get packages with configure built, and in some cases, some small 
  >changes to Makefiles, etc., but that's about it.  Luckily, with both tcl
  and 
  >expect, the build breaks at the linking stage, and after some digging, and 
  >some help from a co-worker whose has previously been through a similar 
  >experience, I was able to get both packages compiled.
  >
  >In the case of tcl, here are the diff(s) for the Makefile generated by 
  >configure, and the changes I made:
  >
  >202c202
  >< LIBS =                   -lnsl $(MATH_LIBS) -lc
  >---
  >> LIBS =                   -lnsl -lsocket $(MATH_LIBS) -lc
  >
  >In the case of expect, here are the diff(s) for the Makefile generated by 
  >configure, and the changes I made:
  >
  >300c300
  >< EXP_AND_TCL_LIBS = $(LDFLAGS)   -lnsl -lm -linet
  >---
  >> EXP_AND_TCL_LIBS = $(LDFLAGS)   -lnsl -lsocket -lm # -linet
  >
  >In both cases, these changes allow the linker to find the BSD-style socket 
  >calls.  I had to remove the reference to inet, because "make expect" orks, 
  >but "make install" fails.  Removing the -linet solved that problem.
  >
  >When configure ran for tcl, I noticed a message which said:
  >
  >"Can't figure out how to do dynamic loading or shared libraries on this 
  >system."
  >
  >I have attached the man page for ld, which mentions dynamic loading and the 
  >options to invoke this (although I believe this is the default).  As
  well, I 
  >have attached the man page for ldd, which is apparently something to list 
  >dynamic dependencies.
  >
  >I'm not sure if this is all the information you need (like I said, my 
  >knowledge of the details of a build process are limited); if not, please
  let 
  >me know.  I will do my best to get you whatever information you need, 

  >providing you can give me some general guidance if things get more 
  >complicated.  Basically, I'm willing to work with you guys if you're
  willing 
  >to put up with my ignorance.

  >Michael Kuhl                       Voice: +1 (905) 637-4807
  >Test Engineer                      FAX:   +1 (905) 637-4730
  >                                   Email: mkuhl@legato.com
  >Legato Systems (Canada) Inc.       WWW:   http://www.legato.com
  >3390 South Service Road
  >Burlington, ON  L7N 3J5


tkt_uuid: 647497ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 8
foundin: None
resolution: Fixed
title: user fontpath priorities ignored on X11
comment:
  (Report forwarded from Debian. The original bug report,
  with analysis and patch, can be seen at
  <http://bugs.debian.org/156118>.)

  This bug was originally reported against Debian's tk
  8.3.3 package, but it is still present in 8.4.1.

  Executive summary:  when scanning X11 fonts, Tk chooses
  the last best match, rather than the first best match
  (in the case where more than one font qualifies as a
  "best" match).  This completely subverts the user's
  chosen priorities, making the user's least preferred
  font into the top choice.  It is, of course, a simple
  case of "<=" being used where "<"  would be
  appropriate.  The simple patch (from Massimo Dal Zotto
  <dz@cs.unitn.it>) is attached.


tkt_uuid: 219936ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Duplicate
title: Tcl/Tk App crashed with X-errrors
comment:
  OriginalBugID: 1390 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '1999-08-14'
  Severity: CRIT
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 1376 716
  OS: Digital Unix
  OSVersion: V4.0B  [Rev. 564]
  Machine: Other
  ClosedDate: '1999-08-14'


  Name:
  Emmanuel Gustin

  Extensions:
  Tix 4.10, PlPlot 980407

  CustomShell:
  Extensions were written to read in data files used in our laboratory, perform calculations on them, and control PlPlot output. They were defined as new Tcl commands. No changes were made to tk. No core commands were redefined.

  ReproducibleScript:
  None available --- behaviour is not reproduced by short scripts,
  for reasons unclear to me. 

  ObservedBehavior:
  System: DEC Alpha machine running DEC OSF/1, X11R6. Compiler
  used is gcc.

  Application: Data processing program using Tcl/Tk as interface
  (8.0.4 but 7.6/4.2 produce the same behaviour, perhaps less
  frequently), extended with Tix (4.1.0), PlPlot as plotting 
  package (release 980407), and own C++ code for I/O and calculations. 

  Behaviour: Crashes frequently when handling user input, typically
  when processing mouse clicks. The system generates errors such as:

    X Error of failed request:  BadWindow (invalid Window parameter)
      Major opcode of failed request:  40 (X_TranslateCoords)
      Resource id in failed request:  0x31
      Serial number of failed request:  1944
      Current serial number in output stream:  1944

  This is typical, but sometimes oter opcodes are displayed.

  If the program is started in a "wish8.0 -sync" shell, the
  program crashes far less often. The type of error reported
  is then:

    Xlib: sequence lost (0x1030a > 0xcbec) in reply type 0x0!
      X Error of failed request:  0
      Major opcode of failed request:  0 ()
      Serial number of failed request:  778
      Current serial number in output stream:  52204

  There are variations in the Major opcode, the values in the (... < ...) 
  part, and the other parameters. A characteristic call stack is:

  #0  exit () at exit.cpp:6
  #1  _XDefaultError (dpy=, event=) at XlibInt.c:2958
  #2  ErrorProc () at ./../generic/tkError.c:5
  #3  _XError (dpy=, rep=) at XlibInt.c:3010
  #4  _XReply (dpy=, rep=, extra=0, discard=1) at XlibInt.c:1900
  #5  XGetWindowAttributes ()
  #6  _XimSetProtoResource ()
  #7  _XimSetICDefaults ()
  #8  WindowEventProc () at ./../generic/tkEvent.c:5
  #9  Tcl_ServiceEvent () at ./../generic/tclNotify.c:5
  #10 TkUnixDoOneXEvent () at ./tkUnixEvent.c:5
  #11 WaitForEvent () at ./tkUnixWm.c:5
  #12 WaitForMapNotify () at ./tkUnixWm.c:5
  #13 TkWmMapWindow () at ./tkUnixWm.c:5
  #14 Tk_MapWindow () at ./../generic/tkWindow.c:5
  #15 MapFrame () at ./../generic/tkFrame.c:5
  #16 TclServiceIdle () at ./../generic/tclTimer.c:5
  #17 Tcl_DoOneEvent () at ./../generic/tclNotify.c:5
  #18 Tk_UpdateCmd () at ./../generic/tkCmds.c:5
  #19 TclInvokeStringCommand () at ./../generic/tclBasic.c:5
  #20 TclExecuteByteCode () at ./../generic/tclExecute.c:5
  #21 Tcl_EvalObj () at ./../generic/tclBasic.c:5
  #22 TclObjInterpProc () at ./../generic/tclProc.c:5
  #23 TclExecuteByteCode () at ./../generic/tclExecute.c:5
  #24 Tcl_EvalObj () at ./../generic/tclBasic.c:5
  #25 Tcl_Eval () at ./../generic/tclBasic.c:5
  #26 Tcl_GlobalEval () at ./../generic/tclBasic.c:5
  #27 Tk_BindEvent () at ./../generic/tkBind.c:5
  #28 TkBindEventProc () at ./../generic/tkCmds.c:5
  #29 Tk_HandleEvent () at ./../generic/tkEvent.c:5
  #30 WindowEventProc () at ./../generic/tkEvent.c:5
  #31 Tcl_ServiceEvent () at ./../generic/tclNotify.c:5
  #32 Tcl_DoOneEvent () at ./../generic/tclNotify.c:5
  #33 Tk_UpdateCmd () at ./../generic/tkCmds.c:5
  #34 TclInvokeStringCommand () at ./../generic/tclBasic.c:5
  #35 TclExecuteByteCode () at ./../generic/tclExecute.c:5
  #36 Tcl_EvalObj () at ./../generic/tclBasic.c:5
  #37 TclObjInterpProc () at ./../generic/tclProc.c:5
  #38 TclExecuteByteCode () at ./../generic/tclExecute.c:5
  #39 Tcl_EvalObj () at ./../generic/tclBasic.c:5
  #40 TclObjInterpProc () at ./../generic/tclProc.c:5
  #41 TclExecuteByteCode () at ./../generic/tclExecute.c:5
  #42 Tcl_EvalObj () at ./../generic/tclBasic.c:5
  #43 Tcl_Eval () at ./../generic/tclBasic.c:5
  #44 Tcl_GlobalEval () at ./../generic/tclBasic.c:5
  #45 Tk_BindEvent () at ./../generic/tkBind.c:5
  #46 TkBindEventProc () at ./../generic/tkCmds.c:5
  #47 Tk_HandleEvent () at ./../generic/tkEvent.c:5
  #48 WindowEventProc () at ./../generic/tkEvent.c:5
  #49 Tcl_ServiceEvent () at ./../generic/tclNotify.c:5
  #50 Tcl_DoOneEvent () at ./../generic/tclNotify.c:5
  #51 Tk_MainLoop () at ./../generic/tkEvent.c:5
  #52 Tk_Main () at ./../generic/tkMain.c:5
  #53 main (argc=2, argv=) at dio_new.cpp:48

  According to the X11 FAQ, 
  see http://www.faqs.org/faqs/x-faq/part7/section-16.html
  and http://www.faqs.org/faqs/x-faq/part7/section-14.html ,
  this type of "Sequence lost" error is caused by an error
  or signal handler making requests to Xlib or Xt, which is 
  illegal. The errors produced when the -sync option is not
  used, indeed do suggest that the status of the X11 system 
  is invalidated. 

  I have considered memory errors within my own code, but there
  is not reason why this should affect the X11 system. I do not
  make any direct calls to X11 functions. 

  The problem arose a few months ago for unknown reasons; previously
  it did not occur (or occured so rarely that it was not reported). 
  No changes were made to the system at that time (I asked the sysop),
  and changes to the program were limited to adding I/O for another
  file format, which seems unlikely to cause a problem like this 
  (besides, the problem also occurs when this new code is not 
  called). Maybe the system load is a factor. 

  More Info about bug:

  Date: Fri, 15 Jan 1999 07:08:12 -0800 (PST)
  To: tclsupport@scriptics.com
  Subject: [Bug Tk 8.0.4] Update on yesterday's bug report: Example script
  From: gustin@uia.ua.ac.be
  Status: O

  Tk 8.0.4 Bug

  Name:  Emmanuel Gustin
  email:  gustin@uia.ua.ac.be
  Support:  None
  Severity:  1
  OperatingSystem:  Digital Unix
  OperatingSystemVersion:  Digital UNIX V4.0B  [Rev. 564]
  Extensions:  Tix 4.1.0, own extensions
  CustomShell:  See yesterday's message
  Synopsis:  Update on yesterday's bug report: Example script

  ReproducibleScript:
  See my report of yesterday. This script generates an Xlib: Sequence lost 
  error on our system, after a number of iterations that is often as low as
  25, but can sometimes be considerably higher:

  #!/usr/local/bin/wish8.0
  for {set i 0} {$i < 120} {incr i} {
    # create windows
    toplevel .a
    toplevel .b
    toplevel .c
    toplevel .d
    button .a.close -text "Close" -command {destroy .a}
    grid .a.close
    button .b.close -text "Close" -command {destroy .b}
    grid .b.close
    button .c.close -text "Close" -command {destroy .c}
    grid .c.close
    button .d.close -text "Close" -command {destroy .d}
    grid .d.close
    update idletasks
    # close windows
    .a.close invoke
    .b.close invoke
    .c.close invoke
    .d.close invoke
    update idletasks
    # log
    puts "$i "
  }

  ObservedBehavior:
  See yesterday. "Xlib: sequence lost" errors. 


tkt_uuid: 220909ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: final: 8.2.3
resolution: Fixed
title: Text in KOI8 encoding displayed incorrectly by text-wdigets
comment:
  OriginalBugID: 5068 Bug
  Version: 8.2.3
  SubmitDate: '2000-04-13'
  LastModified: 
  Severity: SER
  Status: UnAssn
  Submitter: techsupp
  OS: BSD
  OSVersion: FreeBSD


  Name:
  Mikhail Teterin

  Comments:
  I observed this on 3 different machines -- with X-servers being
      Xaccel-3.0, Xaccel-5.0.3 and
      XFree86 running FreeBSD 3.4 and 4.0.

  ReproducibleScript:
  I tried to come up with a script, but the bug is quite elusive :( The only time it reproduces reliably
  is when I use Postilion mailer... So debugging it will be somewhat involved );

  You'll need to install the postilion from http://www.postilion.org/ . Once it is installed,
  create /usr/local/lib/postilion/postilionrc and put the following line into it:

  AddFont koi8-r 14 {} -cronyx-fixed-medium-r-normal--20-200-75-75-c-100-koi8-r

  Start postilion and ensure that Info->Preferences->General->CharacterSize is set to 14...

  Then -- try to read an e-mail in KOI8 encoding (I can send one, when you are ready, with
  the description of how the text should look like by means of xwd(1)).

  ObservedBehavior:
  All of the characters from ASCII half of the table look fine, but the Cyrillic ones appear as so they
  are displayed using a similar (in sizes), but different font.

  The part of Postilion that displays the message's body is fairly simple, and I tried reproducing
  the bug in a simpler script, but failed...

  The tk83 has the same problem as 8.2.3.

  DesiredBehavior:
  I'd blame this on something Postilion does, but the postilion using tk80 displays properly (with the same
  config files, on the same X-server).


tkt_uuid: 2824541fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: None
title: Cannot configure ttk::style -background on Aqua
comment:
  I'm trying to create a custom layout for a ttk::entry widget, but the widget's background cannot be configured on Aqua. Instead of having a matching background with the surrounding widgets/toplevel, the entry displays the default themed background of a ttk::frame. See  http://www.codebykevin.com/pic.png. Code below was tested in the Tcl chatroom by others and they confirmed it works fine under Linux: hence I think it's a Tk-Aqua bug. 

  ---
   set glass {

   R0lGODlhKgAaAOfnAFdZVllbWFpcWVtdWlxeW11fXF9hXmBiX2ZnZWhpZ2lraGxua25wbXJ0
   cXR2c3V3dHZ4dXh6d3x+e31/fH6AfYSGg4eJhoiKh4qMiYuNio2PjHmUqnqVq3yXrZGTkJKU
   kX+asJSWk32cuJWXlIGcs5aYlX6euZeZloOetZial4SftpqbmIWgt4GhvYahuIKivpudmYei
   uYOjv5yem4ijuoSkwIWlwYmlu56gnYamwp+hnoenw4unvaCin4ioxJCnuZykrImpxZmlsoaq
   zI2pv6KkoZGouoqqxpqms4erzaOloo6qwYurx5Kqu5untIiszqSmo5CrwoysyJeqtpOrvJyo
   tZGsw42typSsvaaopZKtxJWtvp6qt4+uy6epppOuxZCvzKiqp5quuZSvxoyx06mrqJWwx42y
   1JKxzpmwwaqsqZaxyI6z1ZqxwqutqpOzz4+01qyuq56yvpizypS00Jm0y5W10Zq1zJa20rCy
   rpu3zqizwbGzr6C3yZy4z7K0saG4yp250LO1sqK5y5660Z+70qO7zKy4xaC806S8zba4taG9
   1KW9zq66x6+7yLi6t6S/1rC8yrm7uLO8xLG9y7q8ubS9xabB2anB07K+zLW+xrO/za7CzrTA
   zrjAyLXBz77BvbbC0K/G2LjD0bnE0rLK28TGw8bIxcLL07vP28HN28rMycvOyr/T38DU4cnR
   2s/RztHT0NLU0cTY5MrW5MvX5dHX2c3Z59bY1dPb5Nbb3dLe7Nvd2t3f3NXh797g3d3j5dnl
   9OPl4eTm4+Ln6tzo9uXn5Obo5eDp8efp5uHq8uXq7ejq5+nr6OPs9Ovu6unu8O3v6+vw8+7w
   7ezx9O/x7vDy7/Hz8O/19/P18vT38/L3+fb49Pf59vX6/fj69/b7/vn7+Pr8+ff9//v9+vz/
   +/7//P//////////////////////////////////////////////////////////////////
   /////////////////////////////////yH/C05FVFNDQVBFMi4wAwEAAAAh+QQJZAD/ACwC
   AAIAKAAWAAAI/gD/CRz4bwUGCg8eQFjIsGHDBw4iTLAQgqBFgisuePCiyJOpUyBDihRpypMi
   Lx8qaLhIMIyGFZ5sAUsmjZrNmzhzWpO2DJgtTysqfGDpxoMbW8ekeQsXzty4p1CjRjUXrps3
   asJsuclQ4uKKSbamMR3n1JzZs2jRkh1HzuxVXX8y4CDYAwqua+DInVrRwMGJU2kDp31KThy1
   XGWGDlxhi1rTPAUICBBAoEAesoIzn6Vm68MKgVAUHftmzhOCBCtQwQKSoABgzZnJdSMmyIPA
   FbCotdUQAIhNa9B6DPCAGbZac+SowVIMRVe4pwkA4GpqDlwuAAmMZx4nTtfnf1mO5JEDNy46
   MHJkxQEDgKC49rPjwC0bqGaZuOoZAKjBPE4NgAzUvYcWOc0QZF91imAnCDHJ5JFAAJN0I2Ba
   4iRDUC/gOEVNDwIUcEABCAgAAATUTIgWOMBYRFp80ghiAQIIVAAEAwJIYI2JZnUji0XSYAYO
   NcsQA8wy0hCTwAASXGOiONFcxAtpTokTHznfiLMNMAkcAMuE43jDC0vLeGOWe2R5o4sn1LgH
   GzkWsvTPMgEOaA433Ag4TjjMuDkQMNi0tZ12sqWoJ0HATMPNffAZZ6U0wLAyqJ62RGoLLrhI
   aqmlpzwaEAAh+QQJZAD/ACwAAAAAKgAaAAAI/gD/CRw40JEhQoEC+fGjcOHCMRAjRkxDsKLF
   f5YcAcID582ZjyBDJhmZZIjJIUySEDHiBMhFghrtdNnRAgSHmzhz6sTZQcSLITx+CHn5bxSk
   Nz5MCMGy55CjTVCjbuJEtSrVQ3uwqDBRQwrFi476SHHxow8qXcemVbPGtm21t3CnTaP27Jgu
   VHtuiIjBsuImQkRiiEEFTNo2cOTMKV7MuLE5cN68QUOGSgwKG1EqJqJDY8+rZt8UjxtNunTj
   cY3DgZOWS46KIFgGjiI0ZIsqaqNNjWjgYMUpx8Adc3v2aosNMAI1DbqyI9WycOb4IAggQEAB
   A3lQBxet/TG4cMpI/tHwYeSfIzxM0uTKNs7UgAQrYL1akaDA7+3bueVqY4NJlUhIcQLNYx8E
   AIQ01mwjTQ8DeNAdfouNA8440GBCQxJY3MEGD6p4Y844CQCAizcSgpMLAAlAuJ03qOyQRBR3
   nEHEK+BMGKIui4kDDAAIPKiiYuSYSMQQRCDCxhiziPMYBgDkEaEaAGQA3Y+MjUPOLFoMoUUh
   cKxRC4ngeILiH8Qkk0cCAUzSDZWpzbLEE1EwggcYqWCj2DNADFDAAQUgIAAAEFDDJmPYqNJF
   F1s4cscTmCDjDTjdSPOHBQggUAEQDAgggTWDPoYMJkFoUdRmddyyjWLeULMMMcAsIw0x4wkM
   IME1g25zyxpHxFYUHmyIggw4H4ojITnfiLMNMAkcAAub4BQjihRdDGTJHmvc4Qo1wD6Imje6
   eILbj+BQ4wqu5Q3ECSJ0FOKKMtv4mBg33Pw4zjbKuBIIE1xYpIkhdQQiyi7OtAucj6dt48wu
   otQhBRa6VvSJIRwhIkotvgRTzMUYZ6xxMcj4QkspeKDxxRhEmUfIHWjAgQcijEDissuXvCyz
   zH7Q8YQURxDhUsn/bCInR3AELfTQZBRt9BBJkCGFFVhMwTNBlnBCSCGEIJQQIAklZMXWRBAR

   RRRWENHwRQEBADs=

  }

  image create photo search1 -data $glass -format "gif -index 0"
  image create photo search2 -data $glass -format "gif -index 1"

      

  ttk::style element create Search.field image {search1  focus search2} \
      -border {22 7 14} -sticky ew 


  ttk::style layout Search.entry {
      Search.field -sticky nswe -border 1 -children {
  Entry.padding -sticky nswe -children {
      Entry.textarea -sticky nswe
  }
      }
  }

  ttk::style configure Search.entry -background #b2b2b2

   . configure -background #b2b2b2
   ttk::entry .e1 -style Search.entry -width 20
   ttk::entry .e2 -style Search.entry -width 20

   grid .e1 -padx 10 -pady 10
   grid .e2 -padx 10 -pady 10


tkt_uuid: 1281228fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5a3
resolution: Fixed
title: Text widget -strictlimits option ignored and undocumented
comment:
  The text widget -strictlimits option for search that was 
  part of the already implemented TIP 155 is 
  undocumented.

  Moreover, this option does not spit any error when used, 
  but it is apparently simply ignored.

  Test case:

  text .t
  pack .t
  .t insert 1.0 "Hello world!\n"
  .t insert 2.0 "This is a test\n"
  set match [.t search -strictlimits -- \
      "world" 1.3 1.8]
  puts $match

  The search occurs between positions 1.3 and 1.8, i.e. 
  the search area does not include the full word "world" 
  that is searched for.

  Nevertheless, a match is found, which means that .t 
  search does not check whether the match it finds is 
  entirely included in the search area or not, despite the 
  presence of the -strictlimits option.

  In a clt thread (see 
  http://groups.google.fr/group/comp.lang.tcl/browse_threa
  d/thread/e80f2586408ab598/2a3660c107cd21ba?
  lnk=st&q=search+unexpected+group:comp.lang.tcl&rnu
  m=1&hl=fr#2a3660c107cd21ba) I was told that some of 
  the implementation of -strictlimits was forgotten, e.g. for 
  regexps. The example above is however no regexp, and 
  the scope of this bug is probably not limited to this sort 
  of search.

  Francois


tkt_uuid: 220542ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: final: 8.1.1
resolution: Fixed
title: Tcl_Exit() before Tk_Init() --> CRASH!
comment:
  OriginalBugID: 2269 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-21'
  LastModified: '1999-06-30'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: redman
  OS: Windows 95
  Machine: X86
  FixedDate: '1999-06-30'
  FixedInVersion: 8.2b1


  Name:

  Don Porter



  Comments:

  Thanks to Paul Duffin for his advice and assistance.



  ReproducibleScript:

  See previous bug report archived at

      

      <URL: http://www.deja.com/=dnc/getdoc.xp?AN=489983570>



  Patch:

  Index: tkWinWm.c

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

  RCS file: /cvsroot/tk/win/tkWinWm.c,v

  retrieving revision 1.8

  diff -c -r1.8 tkWinWm.c

  *** tkWinWm.c1999/04/16 01:51:541.8

  --- tkWinWm.c1999/06/17 19:39:54

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

  *** 518,524 ****

    TkWinWmCleanup(hInstance)

        HINSTANCE hInstance;

    {

  !     ThreadSpecificData *tsdPtr = (ThreadSpecificData *) 

                Tcl_GetThreadData(&dataKey, sizeof(ThreadSpecificData));

    

        if (!tsdPtr->initialized) {

  --- 518,537 ----

    TkWinWmCleanup(hInstance)

        HINSTANCE hInstance;

    {

  !     ThreadSpecificData *tsdPtr;

  ! 

  !     /*

  !      * If we're using stubs to access the Tcl library, and they

  !      * haven't been initialized, we can't call Tcl_GetThreadData.

  !      */

  ! 

  ! #ifdef USE_TCL_STUBS

  !     if (tclStubsPtr == NULL) {

  !         return;

  !     }

  ! #endif

  ! 

  !     tsdPtr = (ThreadSpecificData *) 

                Tcl_GetThreadData(&dataKey, sizeof(ThreadSpecificData));

    

        if (!tsdPtr->initialized) {



  PatchFiles:

  tkWinWm.c





  Applied the patch. 
  -- 06/30/1999 redman


tkt_uuid: 220475ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: Embedded window in text: fatal bug remains
comment:
  OriginalBugID: 1651 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-29'
  LastModified: '1999-04-05'
  Severity: CRIT
  Status: Released
  Submitter: pat
  ChangedBy: stanton
  OS: Other
  Machine: NA
  FixedDate: '1999-04-05'
  FixedInVersion: 8.1b3


  Name:
  Don Porter

  CVS:
  tkTextIndex.c,v 1.1.4.3 1999/03/27 02:31:39

  ReproducibleScript:
      # FILE: demo.tcl
      package require Tk
      set t [text .t]
      $t insert end \n
      $t window create end -window [button $t.b]
      # Modify prior bug demonstration script
      # $t index end-2c
      $t tag add {} end-2c
      pack $t
      



  ObservedBehavior:
      $ wish8.1 demo.tcl
      Segmentation fault (core dumped)
      
      



  DesiredBehavior:
      No crash.
      



  Patch:
  The patch has already been submitted.  See:

  http://www.scriptics.com/patches/tk8.1b1/tkTextIndex.c.991.txt




  PatchFiles:
      tkTextIndex.c
      





      The CVS ChangeLog file contains the entry:
      ===========================================
      1999-03-26    <redman@scriptics.com>
      
              * generic/tkTextIndex.c:
              * tests/testIndex.test: Avoid looking past the beginning of the
              array storing data for the text widget (.t index end-2c).  Added
              test case to check for the bug.  [Bug 991]
      ============================================
      The change to tkTextIndex.c which accompanies that entry does in fact
      make the original script submitted with Bug 991 run correctly.  However,
      it doesn't apply the patch submitted with that bug report, so it doesn't
      fix the underlying bug.  The new script reveals that the bug remains and
      it still has fatal consequences.  Please apply the patch.
      

  The patch has been applied.
  04/05/1999 20:03 - stanton -


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

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


tkt_uuid: 585003ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 81. Portability
priority: 4
foundin: obsolete: 8.3.4
resolution: None
title: tk_popup platform differences
comment:
  tk_popup behaves differently on unix and on windows.

  windows:
    * The <Unmap> binding isn't fired when the popup
  dissapears, which includes when the user doesn't select
  one of the menu items.
    * All processing of the script stops as soon as the
  popup is displayed. The script continues where it left
  off after the popup dissapears.

  unix:
    * Here the <Unmap> binding actually gets fired when
  the popup dissapears.
    * Processing of the script continues after the popup
  is shown. The rest of the script doesn't wait for the
  popup to dissapear. 

  For more information see
  http://mini.net/tcl/3713

  Rohan Pall
  http://www.RohanPall.com


tkt_uuid: 704212ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 55. [focus]
priority: 8
foundin: obsolete: 8.4.2
resolution: None
title: [focus] dumps core with certain extensions
comment:
  The [focus] command will dump core if the target window
  is a widget
  with certain unusual characteristics. If the target
  window is the top
  of a window hierarchy but is NOT a toplevel with a
  wrapper window,
  it will core dump. To demonstrate the problem, get the
  "rootwin"
  widget extension (which makes the X display's root
  window into
  a Tk widget):

   
  http://www.eecs.umich.edu/~mckay/computer/rootwin0.4.tar.gz

  Then do the following:

    load /path/to/libRootwin0.4.so
    rootwin .r
    focus -force .r

  The problem is in tkFocus.c; I fixed it, and the diff
  looks like:


  diff tkFocus.c.orig tkFocus.c
  565c565
  <     TkWindow *topLevelPtr;
  ---
  >     TkWindow *topLevelPtr, *focusToplevelPtr;
  667c667,671
  <       serial =
  TkpChangeFocus(TkpGetWrapperWindow(topLevelPtr), force);
  ---
  >       focusToplevelPtr =
  TkpGetWrapperWindow(topLevelPtr);
  >       if (focusToplevelPtr == NULL) {
  >           focusToplevelPtr = topLevelPtr;
  >       }
  >       serial = TkpChangeFocus(focusToplevelPtr, force);

  NOTE: there's a bad line break in the diff, but you can
  see that
  the fix is simple. Address questions to:

    mckay at eecs dot umich dot edu


tkt_uuid: 228024ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Remind
title: core dumps with canvas
comment:
  I wrote a little application which uses a canvas
  to display pie charts showing disk usage. I used
  bindings of mouse events so that clicking on a 
  pie would zoom in and show the disk usage for
  that pie segment.  

  This worked fine until 8.3.2, now it occasionally
  causes a core dume (occasionally means about a
  50% chance).

  I think the problem is at least in part due to the
  way I re-build the canvas image.  The function that
  gets executed when a pie segment is clicked destroys
  the canvas and then re-builds it.  I've now fixed
  my code so that it just removes all the items from
  the canvas and the core dumps have stopped happening.

  Below is a fairly minimal example that demonstrates the
  problem.  Note that it does not core dump every time.
  Note also I'm running this on a redhat 6.2 system using
  Freewrap 4.4 (I've also tried it on redhat 7.0 using
  tk 8.3.2, same problems.. so i think FreeWrap is not
  guilty).

  http://home.nycap.rr.com/dlabelle/freewrap/freewrap.html

  Note also I was unable to register / log in to the 
  bug system (filled the form in then get told access 
  denied... )

  If you need further information please contact John Gill at
  jng@renre-europe.com


  #!/usr/bin/wish


  proc do_canvas {win} {
      
      eval destroy [winfo children $win]
      
      set c [canvas $win.c -height 200 -width 200]
      pack $c -fill both -expand yes
      
      $c create rectangle 80 80 120 120 -fill blue -tags blue

      # bind a button press to re-build the canvas
      $c bind blue <B1-ButtonRelease> [list do_canvas $win]

      return
  }

  do_canvas .


tkt_uuid: 220570ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 39. Image Basics
priority: 2
foundin: None
resolution: Fixed
title: Img patch for Tk8.2b1
comment:
  OriginalBugID: 2431 RFE
  Version: 8.2b1
  SubmitDate: '1999-07-21'
  LastModified: '1999-11-16'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2325
  OS: Other
  Machine: NA
  FixedDate: '1999-11-16'
  FixedInVersion: 8.3b1


  Name:
  Jan Nijtmans

  Comments:
  Especiall the C-API changes are important to be implemented now, because
      otherwise they have to wait for Tk 8.3. The "window" format handler of
      Img 1.2 depends on it.

  DesiredBehavior:
  This is a follow to BugID: 2325 (which supplied the same fixes for
      Tk8.1.1).
      The difference is that this new patch is re-generated against Tk8.2b1,
      and
      now also contains the full documentation of the required changes in the
      C-API.
      
      This patch adds many enhancements to the "image" command, mainly the
      photo widget. This patch is supplied by Img for a long time, and is from
      time to time enhanced with more features. This version is functionally
      equivalent to the Img 1.2 patch, only it is regenerated and cleaned up
      for use with Tk 8.2b1.
      - 100% objectified (much faster than before). This part is
        originally written by Steve Ball. It makes the image command
        much faster and in addition allows the "-data" option to accept
        binary data.
      - Transparency handled correctly. In order to do this, it was
        necessary to change the internal representation from 3 to 4
        bytes per pixel. The current implementation works for GIF only,
        but this patch moves this code to the Tcl_PhotoPutBlock() function.
        This makes it usable for all image formats, not only GIF.
      - new "imageName data" subcommand. This command allows the content
        of an image to be read into a base-64 encoded string. Currently
        the only way to do that is through a temporary file and an external
        base-64 decoder.
      - new options "-grayscale" and "-background" to the "imageName data"
        and "imageName write" commands. Those options allow colored images
        to be written in grayscale and partially transparent images to be
        written fully opaque. They work for all image formats.
      - GIF format handler has a new "-index" option, which allows to
        extract single images from an animated GIF.
      - C-API changed in order to accomodate the above modifications.
      - All documentation is adapted according to the above
        enhancements, both at the Tcl level and the C-API)
      - Tests adapted to the new commands. However, it is not
        a complete test suite for photo images yet. (The original
        photo test suite is far from complete as well......)

  Patch:
  http://home.wxs.nl/~nijtmans/patch.tk82b1.gz

  PatchFiles:
  tk.h tkImage.c tkImgBmp.c tkImgGIF.c tkImgPPM.c tkImgPhoto.c tkInt.h
      tkTest.c tkWindow.c photo.n image.test imgPhoto.test CrtImgType.3
      CrtPhImgFmt.3 FindPhoto.3 photo.n



  This patch requires modifications to continue to support the char*
  based image types.  The plan is to add this in, but by creating
  Tk_CreateObjImageType Tcl_Obj based funcs parallel to the current
  char* based ones. 
  -- 08/01/1999 hobbs
  Included in 8.3. 
  -- 11/16/1999 hobbs


tkt_uuid: 3363577fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: obsolete: 8.4.14
resolution: Invalid
title: Font in entry widget works at command line, fails in script
comment:
  The following script results in a MS sans Serif font being displayed -- however if I run the configure command on the widget in the console the font changes.  I cant attach the font but you can find it here: http://www2.i-love-epson.co.jp/download/printer/driver/win/page/ttf30.exe.  The font is epgyobld.ttf.  I realize the font maybe non standard (i\'m not sure how to tell) since it doesn't a have a name according to the windows font reader application, but I got the font name via the \"font families\" command, so assume tk knows how to find it.  If you know a font I can use that will display a very brushy japanese script, I am happy to change, or to upgrade tk if this is already fixed.    

  catch {console show} 
  # script 

  global currentKanji 

  set character [entry .entry -text \\u6F22\\u5B57 -font {{EPSON 太行書体Ｂ} 125} -relief flat -textvariable currentKanji]
  set currentKanji \\u6F22\\u5B57

  pack $character 

  # Run this at the command line. 
  $character configure -font {{EPSON 太行書体Ｂ} 125}   


tkt_uuid: 220368ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 2
foundin: obsolete: 8.0
resolution: Fixed
title: menubar problems
comment:
  OriginalBugID: 633 Bug
  Version: 8.0
  SubmitDate: '1998-05-25'
  LastModified: '1999-09-13'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-09-13'
  FixedInVersion: 8.2


  In my app I have a menubar constructed from a frame and a collection
  of menubuttons packed horizontally.

  In Tk8.0 on NT I have a problem when I press the mouse on a menubutton
  (say "File") and then run the mouse across the rest of the menubar.
  What happens is that the first pull-down menu appears under "File",
  but as the mouse (with button 1 down) moves out of the "File" menubutton
  into the next one, "Edit", the "File" pull-down stays posted.
  None of the other pull-downs get posted as the mouse passes over
  their menubutton. Only when I release the mouse does the original
  "File" menu disappear.

  On UNIX this doesn't happen, and it didn't happen in Tk4.2.

  Any ideas what is going on and how I can get the correct behaviour ?

  The big difference I have noticed between Tk8.0 on UNIX and NT seems
  to be that on NT the menu "post" command does not return until the menu
  is actually unposted! This can be seen because the -postcommand is not
  executed on posting but on unposting!

  Mark
  ----

  PS
  I have tried switching over to using the new -menu option on
  toplevel widgets combined with a "-type menubar" menu. This solves
  the problem so long as the toplevel is not marked as "wm transient".
  If the toplevel is transient then the menubar is displayed as usual
  but when the contents of the toplevel are packed they are packed
  over the top of the menubar making it disappear! I need the transient
  behaviour to ensure certain toplevels stay on top of the main toplevel.
  -- 

  ========================================================================
  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 was fixed in later versions of Tk, and works for sure in 8.2 
  -- 09/13/1999 hobbs


tkt_uuid: 220556ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.1
resolution: Fixed
title: I can't get Tk to install per the instructions - I get fatal errors in the make.
comment:
  OriginalBugID: 2356 Bug
  Version: 8.1
  SubmitDate: '1999-07-16'
  LastModified: '1999-08-20'
  Severity: CRIT
  Status: Released
  Submitter: techsupp
  ChangedBy: foster
  OS: Solaris
  Machine: Other
  FixedDate: '1999-08-20'


  Name:
  J. Goss

  CVS:
  RCS: @(#) $Id: README,v 1.16 1999/04/24 01:50:47 stanton Exp $

  ReproducibleScript:
  I issued 'make' and followed all recommendations concerning PATH
      variables and
      directory layout.  Issuing 'make' produces (at the end of make's
      output):
      
      Text relocation remains                         referenced
          against symbol                  offset      in file
      __ctype                             0x1cc       tkGet.o
      __ctype                             0x2a04      tkCanvPs.o
      __ctype                             0x1e8       tkGet.o
      ld: fatal: relocations remain against allocatable but non-writable
      sections
      *** Error code 1
      make: Fatal error: Command failed for target `libtk8.1.so'

  DesiredBehavior:
  How can get it to build?



  Solution provided in:
      http://x46.deja.com/getdoc.xp?AN=499923360 
  -- 08/20/1999 hobbs

  namely: Just hand edit the Makefile to remove the "-z text" ...  
  -- 08/20/1999 foster


tkt_uuid: 632816ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 7 High
foundin: obsolete: 8.4.0
resolution: Fixed
title: cannot remove transient
comment:
  The following should make the toplevel .t
  non-transient, but it retains some partially-transient
  behaviour ( see http://wiki.tcl.tk/3542 )

  toplevel .t
  wm withdraw .t
  update idletasks
  wm transient .t ""
  wm deiconify .t

  Toplevel .t remains 'in front' or 'on top' of the main
  window.. I see the same behaviour in 8.3.4 and 8.4.0 on
  Linux, but not on Windows.


tkt_uuid: 220521ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 2
foundin: obsolete: 8.1
resolution: Fixed
title: GIF write for Tk
comment:
  OriginalBugID: 2039 RFE
  Version: 8.1
  SubmitDate: '1999-05-10'
  LastModified: '1999-11-29'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Linux-Red Hat
  OSVersion: 4.2
  Machine: Other
  FixedDate: '1999-11-29'
  FixedInVersion: 8.3b1


  Name:

  Jan Nijtmans


  Comments:

  The reason that I submit 2 enancements (GIF-write and "<imageName>

      data")

      in one patch, is that they are highly related. At this moment there is

      no way to write image data to a (base-64 encoded) string, only to a

      file. This is a serious limitation, which only can be solved by a patch.

      However, there is currently also no photo format handler for which the

      StringWrite function is implemented. Therefore, there is no way to

      demonstrate this new feature without enhancing at least one format

      handler as well. GIF was simply the most useful candidate.


  DesiredBehavior:

  This enhancement request is essentially the same as:


      http://www.scriptics.com/live/showurl?i=software%2epatches%2etk803&url=%2

      fpatches%2ftk8%2e0%2e3%2fgif%2dwrite%2etxt

      ,only it is upgraded for Tk8.1, and contains a small additional bug-fix

      in the GIF-write function.


      * GIF write function, for example:

         imageName write fileName -format GIF

      This will save the content of the photo in a file, in the popular GIF

      format. In stead of the lzw compression, miGIF compression is used,

      which is a kind of runlength encoding. This compression method is not as

      good as lzw, but it can be decoded by any lzw decompressor and it can

      freely be used without patent problems. (see also the comments in

      tkImgGIF.c) 

      * New "imageName data" command. This command extracts data from the

      photo and transforms it to a string. For example:

          imageName data

      This will return the content of the image in the same format as accepted

      by "imageName put"

        imageName data -format GIF

      This returns the content of the image in base-64 encoded GIF format.

      Extensions can add other formats in the usual way. The "imageName data"

      command accepts the "-to" option in the same way as the "imageName

      write" command. 

      * The photo man page is adapted according to these enhancements. 

      * Tests are added executing all possible branches in the C-code.


      Known limitations:

      * Only images containing less than 255 colors can be written, otherwise

      an error is generated. (color quantisation is not easy to

      implement......)

      * The GIF-write function is not thread-safe yet.


      The "imageName data" command and the GIF write function are already in

      use by the Img extension for about two years. The miGIF compression

      method is more recent: I extracted it from the popular GD library, the

      core library behind Gdtcl.


  Patch:

  *** doc/photo.n.origThu Apr 29 21:37:42 1999

  --- doc/photo.nSun May  9 20:09:42 1999

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

  *** 186,191 ****

  --- 186,214 ----

    default value is the same as \fIx\fR.

    .RE

    .TP

  + \fIimageName \fBdata ?\fIoption value(s) ...\fR?

  + returns image data in the form of a string.

  + The following options may be specified:

  + .RS

  + .TP

  + \fB\-format\fI format-name\fR

  + Specifies the name of the image file format handler to be used to

  + convert the data.  Specifically, this subcommand searches

  + for the first handler whose name matches a initial substring of

  + \fIformat-name\fR and which has the capability to write an string.

  + If this option is not given, the data is returned in the default

  + format as accepted by \fIimageName \fBput\fR?.

  + .TP

  + \fB\-from \fIx1 y1 x2 y2\fR

  + Specifies a rectangular region of \fIimageName\fR to be written to the

  + string.  If only \fIx1\fR and \fIy1\fR are specified, the region

  + extends from \fI(x1,y1)\fR to the bottom-right corner of

  + \fIimageName\fR.  If all four coordinates are given, they specify

  + diagonally opposite corners of the rectangular region.  The default,

  + if this option is not given, is the whole image.

  + .RE

  + .TP

  + 

    \fIimageName \fBget\fR \fIx y\fR

    Returns the color of the pixel at coordinates (\fIx\fR,\fIy\fR) in the

    image as a list of three integers between 0 and 255, representing the

  *** generic/tkImgGIF.c.origThu Apr 29 21:37:52 1999

  --- generic/tkImgGIF.cSun May  9 21:19:20 1999

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

  *** 30,35 ****

  --- 30,37 ----

     * RCS: @(#) $Id: tkImgGIF.c,v 1.3 1999/04/16 01:51:15 stanton Exp $

     */


  + #include "tcl.h"

  + 

    /*

     * GIF's are represented as data in base64 format.

     * base64 strings consist of 4 6-bit characters -> 3 8 bit bytes.

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

  *** 44,49 ****

  --- 46,52 ----

    #define GIF_SPACE(GIF_SPECIAL+2)

    #define GIF_BAD(GIF_SPECIAL+3)

    #define GIF_DONE(GIF_SPECIAL+4)

  + #define GIF_CHAN(GIF_SPECIAL+5)


    /*

     * structure to "mimic" FILE for Mread, so we can look like fread.

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

  *** 55,60 ****

  --- 58,65 ----

        unsigned char *data;/* mmencoded source string */

        int c;/* bits left over from previous character */

        int state;/* decoder state (0-4 or GIF_DONE) */

  +     Tcl_DString *buffer;/* pointer to dynamical string */

  +     int length;/* length of phisical line already written */

    } MFile;


    #include "tkInt.h"

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

  *** 87,92 ****

  --- 92,106 ----

        char *formatString, Tk_PhotoHandle imageHandle,

        int destX, int destY, int width, int height,

        int srcX, int srcY));

  + static int FileWriteGIF _ANSI_ARGS_(( Tcl_Interp *interp,  

  +     char *filename, char *formatString, 

  +     Tk_PhotoImageBlock *blockPtr));

  + static intStringWriteGIF _ANSI_ARGS_((Tcl_Interp *interp,

  +     Tcl_DString *dataPtr, char *formatString,

  +     Tk_PhotoImageBlock *blockPtr));

  + static intCommonWriteGIF _ANSI_ARGS_((Tcl_Interp *interp,

  +     MFile *handle, char *formatString,

  +     Tk_PhotoImageBlock *blockPtr));


    Tk_PhotoImageFormat tkImgFmtGIF = {

    "GIF",/* name */

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

  *** 94,101 ****

    StringMatchGIF, /* stringMatchProc */

    FileReadGIF,    /* fileReadProc */

    StringReadGIF,  /* stringReadProc */

  ! NULL,           /* fileWriteProc */

  ! NULL,           /* stringWriteProc */

    };


    #define INTERLACE0x40

  --- 108,115 ----

    StringMatchGIF, /* stringMatchProc */

    FileReadGIF,    /* fileReadProc */

    StringReadGIF,  /* stringReadProc */

  ! FileWriteGIF,   /* fileWriteProc */

  ! StringWriteGIF, /* stringWriteProc */

    };


    #define INTERLACE0x40

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

  *** 145,150 ****

  --- 159,170 ----

    static intchar64 _ANSI_ARGS_((int c));

    static voidmInit _ANSI_ARGS_((unsigned char *string,

        MFile *handle));

  + static intMputc _ANSI_ARGS_((int c, MFile *handle));

  + static intMwrite _ANSI_ARGS_((MFile *handle,

  +     CONST char *src, int count));

  + static voidmWriteInit _ANSI_ARGS_((Tcl_DString *buffer,

  +     MFile *handle));

  + 

    

    /*

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

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

  *** 1070,1072 ****

  --- 1090,2013 ----

    return Tcl_Read(chan, (char *) dst, (int) (hunk * count));

        }

    }

  + 

  + 

  + /*

  +  * ChanWriteGIF - writes a image in GIF format.

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

  +  * Author:          Lolo

  +  *                              Engeneering Projects Area 

  +  *            Department of Mining 

  +  *                  University of Oviedo

  +  * e-mailzz11425958@zeus.etsimo.uniovi.es

  +  *                  lolo@pcsig22.etsimo.uniovi.es

  +  * Date:            Fri September 20 1996

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

  +  * FileWriteGIF-

  +  *

  +  *    This procedure is called by the photo image type to write

  +  *    GIF format data from a photo image into a given file 

  +  *

  +  * Results:

  +  *A standard TCL completion code.  If TCL_ERROR is returned

  +  *then an error message is left in interp->result.

  +  *

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

  +  */

  + 

  +  /*

  +   *  Types, defines and variables needed to write and compress a GIF.

  +   */

  + 

  + typedef int (* ifunptr) _ANSI_ARGS_((void));

  + 

  + #define LSB(a)                  ((unsigned char) (((short)(a)) & 0x00FF))

  + #define MSB(a)                  ((unsigned char) (((short)(a)) >> 8))

  + 

  + #define GIFBITS 12

  + #define HSIZE  5003            /* 80% occupancy */

  + 

  + static int ssize;

  + static int csize;

  + static int rsize;

  + static unsigned char *pixelo;

  + static int pixelSize;

  + static int pixelPitch;

  + static int greenOffset;

  + static int blueOffset;

  + static int alphaOffset;

  + static int num;

  + static unsigned char mapa[MAXCOLORMAPSIZE][3];

  + 

  + /*

  +  *Definition of new functions to write GIFs

  +  */

  + 

  + static int color _ANSI_ARGS_((int red,int green, int blue));

  + static void compress _ANSI_ARGS_((int init_bits, MFile *handle,

  + ifunptr readValue));

  + static int nuevo _ANSI_ARGS_((int red, int green ,int blue,

  + unsigned char mapa[MAXCOLORMAPSIZE][3]));

  + static int savemap _ANSI_ARGS_((Tk_PhotoImageBlock *blockPtr,

  + unsigned char mapa[MAXCOLORMAPSIZE][3]));

  + static int ReadValue _ANSI_ARGS_((void));

  + static int no_bits _ANSI_ARGS_((int colors));

  + 

  + static int

  + FileWriteGIF (interp, filename, formatString, blockPtr)

  +     Tcl_Interp *interp;/* Interpreter to use for reporting errors. */

  +     char*filename;

  +     char*formatString;

  +     Tk_PhotoImageBlock *blockPtr;

  + {

  +     Tcl_Channel chan = NULL;

  +     MFile handle;

  +     int result;

  + 

  +     chan = Tcl_OpenFileChannel(interp, filename, "w", 0644);

  +     if (!chan) {

  + return TCL_ERROR;

  +     }

  +     if (Tcl_SetChannelOption(interp, chan, "-translation", "binary") != TCL_OK) {

  + return TCL_ERROR;

  +     }

  + 

  +     handle.data = (char *) chan;

  +     handle.state = GIF_CHAN;

  + 

  +     result = CommonWriteGIF(interp, &handle, formatString, blockPtr);

  +     if (Tcl_Close(interp, chan) == TCL_ERROR) {

  + return TCL_ERROR;

  +     }

  +     return result;

  + }

  + 

  + static int

  + StringWriteGIF(interp, dataPtr, formatString, blockPtr)

  +     Tcl_Interp *interp;

  +     Tcl_DString *dataPtr;

  +     char *formatString;

  +     Tk_PhotoImageBlock *blockPtr;

  + {

  +     int result;

  +     MFile handle;

  + 

  +     Tcl_DStringSetLength(dataPtr, 1024);

  +     mWriteInit(dataPtr, &handle);

  + 

  +     result = CommonWriteGIF(interp, &handle, formatString, blockPtr);

  +     Mputc(GIF_DONE, &handle);

  + 

  +     return(result);

  + }

  + 

  + static int

  + CommonWriteGIF(interp, handle, formatString, blockPtr)

  +     Tcl_Interp *interp;

  +     MFile *handle;

  +     char *formatString;

  +     Tk_PhotoImageBlock *blockPtr;

  + {

  +     int  resolution;

  +     long  numcolormap;

  + 

  +     long  width,height,x;

  +     unsigned char c;

  +     unsigned int top,left;

  +     int num;

  + 

  +     top = 0;

  +     left = 0;

  + 

  +     pixelSize=blockPtr->pixelSize;

  +     greenOffset=blockPtr->offset[1]-blockPtr->offset[0];

  +     blueOffset=blockPtr->offset[2]-blockPtr->offset[0];

  +     alphaOffset = blockPtr->offset[0];

  +     if (alphaOffset < blockPtr->offset[2]) {

  + alphaOffset = blockPtr->offset[2];

  +     }

  +     if (++alphaOffset < pixelSize) {

  + alphaOffset -= blockPtr->offset[0];

  +     } else {

  + alphaOffset = 0;

  +     }

  + 

  +     Mwrite(handle, (CONST char *) (alphaOffset ? "GIF89a":"GIF87a"), 6);

  + 

  +     for (x=0;x<MAXCOLORMAPSIZE;x++) {

  + mapa[x][CM_RED] = 255;

  + mapa[x][CM_GREEN] = 255;

  + mapa[x][CM_BLUE] = 255;

  +     }

  + 

  + 

  +     width=blockPtr->width;

  +     height=blockPtr->height;

  +     pixelo=blockPtr->pixelPtr + blockPtr->offset[0];

  +     pixelPitch=blockPtr->pitch;

  +     if ((num=savemap(blockPtr,mapa))<0) {

  + Tcl_AppendResult(interp, "too many colors", (char *) NULL);

  + return TCL_ERROR;

  +     }

  +     if (num<3) num=3;

  +     c=LSB(width);

  +     Mputc(c,handle);

  +     c=MSB(width);

  +     Mputc(c,handle);

  +     c=LSB(height);

  +     Mputc(c,handle);

  +     c=MSB(height);

  +     Mputc(c,handle);

  + 

  +     c= (1 << 7) | (no_bits(num) << 4) | (no_bits(num));

  +     Mputc(c,handle);

  +     resolution = no_bits(num)+1;

  + 

  +     numcolormap=1 << resolution;

  + 

  +     /*  background color */

  + 

  +     Mputc(0,handle);

  + 

  +     /*  zero for future expansion  */

  + 

  +     Mputc(0,handle);

  + 

  +     for (x=0; x<numcolormap ;x++) {

  + Mputc(mapa[x][CM_RED],handle);

  + Mputc(mapa[x][CM_GREEN],handle);

  + Mputc(mapa[x][CM_BLUE],handle);

  +     }

  + 

  +     /*

  +      * Write out extension for transparent colour index, if necessary.

  +      */

  + 

  +     if (alphaOffset) {

  + Mwrite(handle, "!\371\4\1\0\0\0", 8);

  +     }

  + 

  +     Mputc(',',handle);

  +     c=LSB(top);

  +     Mputc(c,handle);

  +     c=MSB(top);

  +     Mputc(c,handle);

  +     c=LSB(left);

  +     Mputc(c,handle);

  +     c=MSB(left);

  +     Mputc(c,handle);

  + 

  +     c=LSB(width);

  +     Mputc(c,handle);

  +     c=MSB(width);

  +     Mputc(c,handle);

  + 

  +     c=LSB(height);

  +     Mputc(c,handle);

  +     c=MSB(height);

  +     Mputc(c,handle);

  + 

  +     c=0;

  +     Mputc(c,handle);

  +     c=resolution;

  +     Mputc(c,handle);

  + 

  +     ssize = rsize = blockPtr->width;

  +     csize = blockPtr->height;

  +     compress(resolution+1, handle, ReadValue);

  +  

  +     Mputc(0,handle);

  +     Mputc(';',handle);

  + 

  +     return TCL_OK;

  + }

  + 

  + static int

  + color(red, green, blue)

  +     int red;

  +     int green;

  +     int blue;

  + {

  +     int x;

  +     for (x=(alphaOffset != 0);x<=MAXCOLORMAPSIZE;x++) {

  + if ((mapa[x][CM_RED]==red) && (mapa[x][CM_GREEN]==green) &&

  + (mapa[x][CM_BLUE]==blue)) {

  +     return x;

  + }

  +     }

  +     return -1;

  + }

  + 

  + 

  + static int

  + nuevo(red, green, blue, mapa)

  +     int red,green,blue;

  +     unsigned char mapa[MAXCOLORMAPSIZE][3];

  + {

  +     int x;

  +     for (x=(alphaOffset != 0);x<num;x++) {

  + if ((mapa[x][CM_RED]==red) && (mapa[x][CM_GREEN]==green) &&

  + (mapa[x][CM_BLUE]==blue)) {

  +     return 0;

  + }

  +     }

  +     return 1;

  + }

  + 

  + static int

  + savemap(blockPtr,mapa)

  +     Tk_PhotoImageBlock *blockPtr;

  +     unsigned char mapa[MAXCOLORMAPSIZE][3];

  + {

  +     unsigned char  *colores;

  +     int x,y;

  +     unsigned char  red,green,blue;

  + 

  +     if (alphaOffset) {

  + num = 1;

  + mapa[0][CM_RED] = 0xd9;

  + mapa[0][CM_GREEN] = 0xd9;

  + mapa[0][CM_BLUE] = 0xd9;

  +     } else {

  + num = 0;

  +     }

  + 

  +     for(y=0;y<blockPtr->height;y++) {

  + colores=blockPtr->pixelPtr + blockPtr->offset[0]

  + + y * blockPtr->pitch;

  + for(x=0;x<blockPtr->width;x++) {

  +     if (!alphaOffset || (colores[alphaOffset] != 0)) {

  + red = colores[0];

  + green = colores[greenOffset];

  + blue = colores[blueOffset];

  + if (nuevo(red,green,blue,mapa)) {

  +     if (num>255) 

  + return -1;

  + 

  +     mapa[num][CM_RED]=red;

  +     mapa[num][CM_GREEN]=green;

  +     mapa[num][CM_BLUE]=blue;

  +     num++;

  + }

  +     }

  +     colores += pixelSize;

  + }

  +     }

  +     return num-1;

  + }

  + 

  + static int

  + ReadValue()

  + {

  +     unsigned int col;

  + 

  +     if (csize == 0) {

  + return EOF;

  +     }

  +     if (alphaOffset && (pixelo[alphaOffset]==0)) {

  + col = 0;

  +     } else {

  + col = color(pixelo[0],pixelo[greenOffset],pixelo[blueOffset]);

  +     }

  +     pixelo += pixelSize;

  +     if (--ssize <= 0) {

  + ssize = rsize;

  + csize--;

  + pixelo += pixelPitch - (rsize * pixelSize);

  +     }

  + 

  +     return col;

  + }

  + 

  + /*

  +  * Return the number of bits ( -1 ) to represent a given

  +  * number of colors ( ex: 256 colors => 7 ).

  +  */

  + static int

  + no_bits( colors )

  + int colors;

  + {

  +     register int bits = 0;

  + 

  +     colors--;

  +     while ( colors >> bits ) {

  + bits++;

  +     }

  + 

  +     return (bits-1);

  + }

  + 

  + /*

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

  +  * Mwrite --

  +  *

  +  *  This procedure is invoked to put imaged data into a stream

  +  *  using Mputc.

  +  *

  +  * Results:

  +  *  The return value is the number of characters "written"

  +  *

  +  * Side effects:

  +  *  The base64 handle will change state.

  +  *

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

  +  */

  + 

  + int

  + Mwrite(handle, src, count)

  +     MFile *handle;/* mmencode "file" handle */

  +     CONST char *src;/* where to get the data */

  +     int count;/* number of bytes */

  + {

  +     register int i;

  +     int curcount, bufcount;

  + 

  +     if (handle->state == GIF_CHAN) {

  + return Tcl_Write((Tcl_Channel) handle->data, (char *) src, count);

  +     }

  +     curcount = (char *) handle->data - Tcl_DStringValue(handle->buffer);

  +     bufcount = curcount + count + count/3 + count/52 + 1024;

  + 

  +     /* make sure that the DString contains enough space */

  +     if (bufcount >= (handle->buffer->spaceAvl)) {

  + Tcl_DStringSetLength(handle->buffer, bufcount + 4096);

  + handle->data = Tcl_DStringValue(handle->buffer) + curcount;

  +     }

  +     /* write the data */

  +     for (i=0; (i<count) && (Mputc(*src++, handle) != GIF_DONE); i++) {

  + /* empty loop body */

  +     }

  +     return i;

  + }

  + /*

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

  +  *

  +  * Mputc --

  +  *

  +  *  This procedure encodes and writes the next byte to a base64

  +  *  encoded string.

  +  *

  +  * Results:

  +  *  The written byte is returned.

  +  *

  +  * Side effects:

  +  *  the base64 handle will change state.

  +  *

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

  +  */

  + 

  + static char base64_table[64] = {

  +     'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H',

  +     'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P',

  +     'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X',

  +     'Y', 'Z', 'a', 'b', 'c', 'd', 'e', 'f',

  +     'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n',

  +     'o', 'p', 'q', 'r', 's', 't', 'u', 'v',

  +     'w', 'x', 'y', 'z', '0', '1', '2', '3',

  +     '4', '5', '6', '7', '8', '9', '+', '/'

  + };

  + 

  + int

  + Mputc(c, handle)

  +     register int c;/* character to be written */

  +     register MFile *handle;/* handle containing decoder data and state */

  + {

  +     /* In fact, here should be checked first if the dynamic

  +      * string contains enough space for the next character.

  +      * This would be very expensive to do for each character.

  +      * Therefore we just allocate 1024 bytes immediately in

  +      * the beginning and also take a 1024 bytes margin inside

  +      * every Mwrite. At least this check is done then only

  +      * every 256 bytes, which is much faster. Because the GIF

  +      * header is less than 1024 bytes and pixel data is

  +      * written in 256 byte portions, this should be safe.

  +      */

  + 

  +     if (c == GIF_DONE) {

  + switch(handle->state) {

  +     case 0:

  + break;

  +     case 1:

  + *handle->data++ = base64_table[(handle->c<<4)&63];

  + *handle->data++ = '='; *handle->data++ = '='; break;

  +     case 2:

  + *handle->data++ = base64_table[(handle->c<<2)&63];

  + *handle->data++ = '='; break;

  +     default:

  + handle->state = GIF_DONE;

  + return GIF_DONE;

  + }

  + Tcl_DStringSetLength(handle->buffer,

  + (char *) handle->data - Tcl_DStringValue(handle->buffer));

  + handle->state = GIF_DONE;

  + return GIF_DONE;

  +     }

  + 

  +     if (handle->state == GIF_CHAN) {

  + char ch = (char) c;

  + return (Tcl_Write((Tcl_Channel) handle->data, &ch, 1)>0) ? c : GIF_DONE;

  +     }

  + 

  +     c &= 0xff;

  +     switch (handle->state++) {

  + case 0:

  +     *handle->data++ = base64_table[(c>>2)&63]; break;

  + case 1:

  +     c |= handle->c << 8;

  +     *handle->data++ = base64_table[(c>>4)&63]; break;

  + case 2:

  +     handle->state = 0;

  +     c |= handle->c << 8;

  +     *handle->data++ = base64_table[(c>>6)&63];

  +     *handle->data++ = base64_table[c&63]; break;

  +     }

  +     handle->c = c;

  +     if (handle->length++ > 52) {

  + handle->length = 0;

  + *handle->data++ = '\n';

  +     }

  +     return c & 0xff;

  + };

  + 

  + /*

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

  +  * mWriteInit --

  +  *  This procedure initializes a base64 decoder handle for writing

  +  *

  +  * Results:

  +  *  none

  +  *

  +  * Side effects:

  +  *  the base64 handle is initialized

  +  *

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

  +  */

  + 

  + void

  + mWriteInit(buffer, handle)

  +     Tcl_DString *buffer;

  +     MFile *handle;/* mmencode "file" handle */

  + {

  +     Tcl_DStringSetLength(buffer, buffer->spaceAvl);

  +     handle->buffer = buffer;

  +     handle->data = Tcl_DStringValue(buffer);

  +     handle->state = 0;

  +     handle->length = 0;

  + }

  + 

  + 

  + 

  + /*-----------------------------------------------------------------------

  +  *

  +  * miGIF Compression - mouse and ivo's GIF-compatible compression

  +  *

  +  *          -run length encoding compression routines-

  +  *

  +  * Copyright (C) 1998 Hutchison Avenue Software Corporation

  +  *               http://www.hasc.com

  +  *               info@hasc.com

  +  *

  +  * Permission to use, copy, modify, and distribute this software and its

  +  * documentation for any purpose and without fee is hereby granted, provided

  +  * that the above copyright notice appear in all copies and that both that

  +  * copyright notice and this permission notice appear in supporting

  +  * documentation.  This software is provided "AS IS." The Hutchison Avenue 

  +  * Software Corporation disclaims all warranties, either express or implied, 

  +  * including but not limited to implied warranties of merchantability and 

  +  * fitness for a particular purpose, with respect to this code and accompanying

  +  * documentation. 

  +  * 

  +  * The miGIF compression routines do not, strictly speaking, generate files 

  +  * conforming to the GIF spec, since the image data is not LZW-compressed 

  +  * (this is the point: in order to avoid transgression of the Unisys patent 

  +  * on the LZW algorithm.)  However, miGIF generates data streams that any 

  +  * reasonably sane LZW decompresser will decompress to what we want.

  +  *

  +  * miGIF compression uses run length encoding. It compresses horizontal runs 

  +  * of pixels of the same color. This type of compression gives good results

  +  * on images with many runs, for example images with lines, text and solid 

  +  * shapes on a solid-colored background. It gives little or no compression 

  +  * on images with few runs, for example digital or scanned photos.

  +  *

  +  *                               der Mouse

  +  *                      mouse@rodents.montreal.qc.ca

  +  *            7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

  +  *

  +  *                             ivo@hasc.com

  +  *

  +  * The Graphics Interchange Format(c) is the Copyright property of

  +  * CompuServe Incorporated.  GIF(sm) is a Service Mark property of

  +  * CompuServe Incorporated.

  +  *

  +  */

  + 

  + static int rl_pixel;

  + static int rl_basecode;

  + static int rl_count;

  + static int rl_table_pixel;

  + static int rl_table_max;

  + static int just_cleared;

  + static int out_bits;

  + static int out_bits_init;

  + static int out_count;

  + static int out_bump;

  + static int out_bump_init;

  + static int out_clear;

  + static int out_clear_init;

  + static int max_ocodes;

  + static int code_clear;

  + static int code_eof;

  + static unsigned int obuf;

  + static int obits;

  + static MFile *ofile;

  + static unsigned char oblock[256];

  + static int oblen;

  + 

  + /* Used only when debugging GIF compression code */

  + /* #define DEBUGGING_ENVARS */

  + 

  + #ifdef DEBUGGING_ENVARS

  + 

  + static int verbose_set = 0;

  + static int verbose;

  + #define VERBOSE (verbose_set?verbose:set_verbose())

  + 

  + static int set_verbose(void)

  + {

  +  verbose = !!getenv("GIF_VERBOSE");

  +  verbose_set = 1;

  +  return(verbose);

  + }

  + 

  + #else

  + 

  + #define VERBOSE 0

  + 

  + #endif

  + 

  + 

  + static const char *

  + binformat(v, nbits)

  +     unsigned int v;

  +     int nbits;

  + {

  +  static char bufs[8][64];

  +  static int bhand = 0;

  +  unsigned int bit;

  +  int bno;

  +  char *bp;

  + 

  +  bhand --;

  +  if (bhand < 0) bhand = (sizeof(bufs)/sizeof(bufs[0]))-1;

  +  bp = &bufs[bhand][0];

  +  for (bno=nbits-1,bit=1U<<bno;bno>=0;bno--,bit>>=1)

  +   { *bp++ = (v & bit) ? '1' : '0';

  +     if (((bno&3) == 0) && (bno != 0)) *bp++ = '.';

  +   }

  +  *bp = '\0';

  +  return(&bufs[bhand][0]);

  + }

  + 

  + static void write_block()

  + {

  +  int i;

  +  unsigned char c;

  + 

  +  if (VERBOSE)

  +   { printf("write_block %d:",oblen);

  +     for (i=0;i<oblen;i++) printf(" %02x",oblock[i]);

  +     printf("\n");

  +   }

  +  c = oblen;

  +  Mwrite(ofile, (CONST char *) &c, 1);

  +  Mwrite(ofile, &oblock[0], oblen);

  +  oblen = 0;

  + }

  + 

  + static void

  + block_out(c)

  +     unsigned char c;

  + {

  +  if (VERBOSE) printf("block_out %s\n",binformat(c,8));

  +  oblock[oblen++] = c;

  +  if (oblen >= 255) write_block();

  + }

  + 

  + static void block_flush()

  + {

  +  if (VERBOSE) printf("block_flush\n");

  +  if (oblen > 0) write_block();

  + }

  + 

  + static void output(val)

  +     int val;

  + {

  +  if (VERBOSE) printf("output %s [%s %d %d]\n",binformat(val,out_bits),binformat(obuf,obits),obits,out_bits);

  +  obuf |= val << obits;

  +  obits += out_bits;

  +  while (obits >= 8)

  +   { block_out(obuf&0xff);

  +     obuf >>= 8;

  +     obits -= 8;

  +   }

  +  if (VERBOSE) printf("output leaving [%s %d]\n",binformat(obuf,obits),obits);

  + }

  + 

  + static void output_flush()

  + {

  +  if (VERBOSE) printf("output_flush\n");

  +  if (obits > 0) block_out(obuf);

  +  block_flush();

  + }

  + 

  + static void did_clear()

  + {

  +  if (VERBOSE) printf("did_clear\n");

  +  out_bits = out_bits_init;

  +  out_bump = out_bump_init;

  +  out_clear = out_clear_init;

  +  out_count = 0;

  +  rl_table_max = 0;

  +  just_cleared = 1;

  + }

  + 

  + static void

  + output_plain(c)

  +     int c;

  + {

  +  if (VERBOSE) printf("output_plain %s\n",binformat(c,out_bits));

  +  just_cleared = 0;

  +  output(c);

  +  out_count ++;

  +  if (out_count >= out_bump)

  +   { out_bits ++;

  +     out_bump += 1 << (out_bits - 1);

  +   }

  +  if (out_count >= out_clear)

  +   { output(code_clear);

  +     did_clear();

  +   }

  + }

  + 

  + static unsigned int isqrt(x)

  +     unsigned int x;

  + {

  +  unsigned int r;

  +  unsigned int v;

  + 

  +  if (x < 2) return(x);

  +  for (v=x,r=1;v;v>>=2,r<<=1) ;

  +  while (1)

  +   { v = ((x / r) + r) / 2;

  +     if ((v == r) || (v == r+1)) return(r);

  +     r = v;

  +   }

  + }

  + 

  + static unsigned int

  + compute_triangle_count(count, nrepcodes)

  +     unsigned int count;

  +     unsigned int nrepcodes;

  + {

  +  unsigned int perrep;

  +  unsigned int cost;

  + 

  +  cost = 0;

  +  perrep = (nrepcodes * (nrepcodes+1)) / 2;

  +  while (count >= perrep)

  +   { cost += nrepcodes;

  +     count -= perrep;

  +   }

  +  if (count > 0)

  +   { unsigned int n;

  +     n = isqrt(count);

  +     while ((n*(n+1)) >= 2*count) n --;

  +     while ((n*(n+1)) < 2*count) n ++;

  +     cost += n;

  +   }

  +  return(cost);

  + }

  + 

  + static void max_out_clear()

  + {

  +  out_clear = max_ocodes;

  + }

  + 

  + static void reset_out_clear()

  + {

  +  out_clear = out_clear_init;

  +  if (out_count >= out_clear)

  +   { output(code_clear);

  +     did_clear();

  +   }

  + }

  + 

  + static void

  + rl_flush_fromclear(count)

  +     int count;

  + {

  +  int n;

  + 

  +  if (VERBOSE) printf("rl_flush_fromclear %d\n",count);

  +  max_out_clear();

  +  rl_table_pixel = rl_pixel;

  +  n = 1;

  +  while (count > 0)

  +   { if (n == 1)

  +      { rl_table_max = 1;

  +        output_plain(rl_pixel);

  +        count --;

  +      }

  +     else if (count >= n)

  +      { rl_table_max = n;

  +        output_plain(rl_basecode+n-2);

  +        count -= n;

  +      }

  +     else if (count == 1)

  +      { rl_table_max ++;

  +        output_plain(rl_pixel);

  +        count = 0;

  +      }

  +     else

  +      { rl_table_max ++;

  +        output_plain(rl_basecode+count-2);

  +        count = 0;

  +      }

  +     if (out_count == 0) n = 1; else n ++;

  +   }

  +  reset_out_clear();

  +  if (VERBOSE) printf("rl_flush_fromclear leaving table_max=%d\n",rl_table_max);

  + }

  + 

  + static void rl_flush_clearorrep(count)

  +     int count;

  + {

  +  int withclr;

  + 

  +  if (VERBOSE) printf("rl_flush_clearorrep %d\n",count);

  +  withclr = 1 + compute_triangle_count(count,max_ocodes);

  +  if (withclr < count)

  +   { output(code_clear);

  +     did_clear();

  +     rl_flush_fromclear(count);

  +   }

  +  else

  +   { for (;count>0;count--) output_plain(rl_pixel);

  +   }

  + }

  + 

  + static void rl_flush_withtable(count)

  +     int count;

  + {

  +  int repmax;

  +  int repleft;

  +  int leftover;

  + 

  +  if (VERBOSE) printf("rl_flush_withtable %d\n",count);

  +  repmax = count / rl_table_max;

  +  leftover = count % rl_table_max;

  +  repleft = (leftover ? 1 : 0);

  +  if (out_count+repmax+repleft > max_ocodes)

  +   { repmax = max_ocodes - out_count;

  +     leftover = count - (repmax * rl_table_max);

  +     repleft = 1 + compute_triangle_count(leftover,max_ocodes);

  +   }

  +  if (VERBOSE) printf("rl_flush_withtable repmax=%d leftover=%d repleft=%d\n",repmax,leftover,repleft);

  +  if (1+compute_triangle_count(count,max_ocodes) < repmax+repleft)

  +   { output(code_clear);

  +     did_clear();

  +     rl_flush_fromclear(count);

  +     return;

  +   }

  +  max_out_clear();

  +  for (;repmax>0;repmax--) output_plain(rl_basecode+rl_table_max-2);

  +  if (leftover)

  +   { if (just_cleared)

  +      { rl_flush_fromclear(leftover);

  +      }

  +     else if (leftover == 1)

  +      { output_plain(rl_pixel);

  +      }

  +     else

  +      { output_plain(rl_basecode+leftover-2);

  +      }

  +   }

  +  reset_out_clear();

  + }

  + 

  + static void rl_flush()

  + {

  +  if (VERBOSE) printf("rl_flush [ %d %d\n",rl_count,rl_pixel);

  +  if (rl_count == 1)

  +   { output_plain(rl_pixel);

  +     rl_count = 0;

  +     if (VERBOSE) printf("rl_flush ]\n");

  +     return;

  +   }

  +  if (just_cleared)

  +   { rl_flush_fromclear(rl_count);

  +   }

  +  else if ((rl_table_max < 2) || (rl_table_pixel != rl_pixel))

  +   { rl_flush_clearorrep(rl_count);

  +   }

  +  else

  +   { rl_flush_withtable(rl_count);

  +   }

  +  if (VERBOSE) printf("rl_flush ]\n");

  +  rl_count = 0;

  + }

  + 

  + 

  + static void compress( init_bits, handle, readValue )

  +     int init_bits;

  +     MFile *handle;

  +     ifunptr readValue;

  + {

  +  int c;

  + 

  +  ofile = handle;

  +  obuf = 0;

  +  obits = 0;

  +  oblen = 0;

  +  code_clear = 1 << (init_bits - 1);

  +  code_eof = code_clear + 1;

  +  rl_basecode = code_eof + 1;

  +  out_bump_init = (1 << (init_bits - 1)) - 1;

  +  /* for images with a lot of runs, making out_clear_init larger will

  +     give better compression. */ 

  +  out_clear_init = (init_bits <= 3) ? 9 : (out_bump_init-1);

  + #ifdef DEBUGGING_ENVARS

  +   { const char *ocienv;

  +     ocienv = getenv("GIF_OUT_CLEAR_INIT");

  +     if (ocienv)

  +      { out_clear_init = atoi(ocienv);

  +        if (VERBOSE) printf("[overriding out_clear_init to %d]\n",out_clear_init);

  +      }

  +   }

  + #endif

  +  out_bits_init = init_bits;

  +  max_ocodes = (1 << GIFBITS) - ((1 << (out_bits_init - 1)) + 3);

  +  did_clear();

  +  output(code_clear);

  +  rl_count = 0;

  +  while (1)

  +   { c = readValue();

  +     if ((rl_count > 0) && (c != rl_pixel)) rl_flush();

  +     if (c == EOF) break;

  +     if (rl_pixel == c)

  +      { rl_count ++;

  +      }

  +     else

  +      { rl_pixel = c;

  +        rl_count = 1;

  +      }

  +   }

  +  output(code_eof);

  +  output_flush();

  + }

  + 

  + /*-----------------------------------------------------------------------

  +  *

  +  * End of miGIF section  - See copyright notice at start of section.

  +  *

  +  *-----------------------------------------------------------------------*/

  *** generic/tkImgPhoto.c.origThu Apr 29 21:37:53 1999

  --- generic/tkImgPhoto.cSun May  9 20:28:01 1999

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

  *** 364,369 ****

  --- 364,372 ----

        int width, int height));

    static voidImgPhotoInstanceSetSize _ANSI_ARGS_((

        PhotoInstance *instancePtr));

  + static intImgStringWrite _ANSI_ARGS_((Tcl_Interp *interp,

  +     Tcl_DString *dataPtr, char *formatString,

  +     Tk_PhotoImageBlock *blockPtr));

    static intIsValidPalette _ANSI_ARGS_((PhotoInstance *instancePtr,

        char *palette));

    static intCountBits _ANSI_ARGS_((pixel mask));

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

  *** 684,689 ****

  --- 687,781 ----

    options.toY2 - options.toY, options.zoomX, options.zoomY,

    options.subsampleX, options.subsampleY);


  +     } else if ((c == 'd') && (strncmp(argv[1], "data", length) == 0)) {

  + /*

  +  * photo data command - first parse and check parameters.

  +  */

  + Tk_PhotoImageBlock block;

  + Tcl_DString buffer;

  + 

  + Tk_ImageStringWriteProc *stringWriteProc = NULL;

  + 

  + index = 2;

  + memset((VOID *) &options, 0, sizeof(options));

  + options.name = NULL;

  + options.format = NULL;

  + options.



  These are integrated with 8.3. 
  -- 11/29/1999 hobbs


tkt_uuid: 220072ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 1 Zero
foundin: None
resolution: Duplicate
title: XIM support for Tk
comment:
  OriginalBugID: 4280 RFE
  Version: 8.3
  SubmitDate: '2000-03-01'
  LastModified: '2000-05-10'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4143 5425
  OS: All Unix
  ClosedDate: '2000-05-10'


  Name:

  Jan Nijtmans


  DesiredBehavior:

  Currently, XIM support doesn't work yet on UNIX. Here are the patches originally

  written by m-hirano <m-hirano@sra.co.jp> to make everything work.

  My adaptations are only related to some simplifications, moving part of

  the changes fro Tcl to Tk.

  This patch needs the following fix to Tcl, already contributed. See:

    http://www.deja.com/=dnc/getdoc.xp?AN=588973271


  Patch:

  *** unix/configure.in.origThu Feb 10 12:11:02 2000

  --- unix/configure.inSun Feb 27 09:43:40 2000

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

  *** 372,377 ****

  --- 372,484 ----

    TK_SHARED_BUILD=${SHARED_BUILD}


    #--------------------------------------------------------------------

  + #Checking X lib for i18n related things.

  + #--------------------------------------------------------------------

  + 

  + X11_IMAKE_FLAGS=""

  + tk_oldCflags=$CFLAGS

  + tk_oldLibs=$LIBS

  + CFLAGS="$CFLAGS $XINCLUDES"

  + LIBS="$XLIBSW $LIBS"

  + 

  + AC_MSG_CHECKING([XRegisterIMInstantiateCallback])

  + AC_TRY_LINK([

  + #include <X11/Xlib.h>

  + ], [

  + XRegisterIMInstantiateCallback(0, 0, 0, 0, 0, 0);

  + ], [

  + AC_MSG_RESULT(yes)

  + X11_IMAKE_FLAGS="-DHAVE_XIMREGINSTCB"

  + ], [

  + AC_MSG_RESULT(no)

  + ])

  + 

  + AC_MSG_CHECKING([XIDProc])

  + AC_TRY_COMPILE([

  + #include <X11/Xlib.h>

  + ], [

  + XIDProc *a;

  + ], [

  + AC_MSG_RESULT(yes)

  + ], [

  + AC_MSG_RESULT(no)

  + X11_IMAKE_FLAGS="$X11_IMAKE_FLAGS -DNO_XIDPROC"

  + ])

  + 

  + HAVE_XMKMF=""

  + AC_PATH_PROG(HAVE_XMKMF, xmkmf, "", /usr/X11R6/bin /usr/X11R5/bin /usr/local/X11R6/bin /usr/local/X11R5/bin /usr/openwin/bin /usr/X11/bin /usr/X386/bin /usr/sww/bin /usr/unsupported/bin)

  + if test "X$HAVE_XMKMF" != "X"; then

  +     IMAKE_FLAGS=""

  +     if test -d ImakeCheck; then

  +         rm -rf ImakeCheck

  +     fi

  +     mkdir ImakeCheck

  +     cat << EOF > ImakeCheck/Imakefile

  + SRCS = dummy.c

  + OBJS = dummy.o

  + 

  + ComplexProgramTarget(dummy)

  + EOF

  +     cat << EOF > ImakeCheck/dummy.c

  + static int justAnInt = 0;

  + EOF

  +     (cd ./ImakeCheck; rm -f Makefile Makefile.*; eval $HAVE_XMKMF) > /dev/null 2>&1

  +     for i in `(cd ./ImakeCheck; make -n dummy.o)`

  +     do

  +         case $i in -D*) IMAKE_FLAGS="$IMAKE_FLAGS $i";; esac

  +     done

  +     if test "X$IMAKE_FLAGS" != "X"; then

  +         AC_MSG_RESULT(Add these flags for proper compile: $IMAKE_FLAGS)

  +         X11_IMAKE_FLAGS="$X11_IMAKE_FLAGS $IMAKE_FLAGS"

  +     fi

  +     rm -rf ImakeCheck

  + fi

  + 

  + # At last check FreeBSD and have -lxpg4.

  + AC_MSG_CHECKING([system version (for additional locale library)])

  + if test -f /usr/lib/NextStep/software_version; then

  +     system=NEXTSTEP-`awk '/3/,/3/' /usr/lib/NextStep/software_version`

  + else

  +     system=`uname -s`-`uname -r`

  +     if test "$?" -ne 0 ; then

  +         system=unknown

  +     else

  +         # Special check for weird MP-RAS system (uname returns weird

  +         # results, and the version is kept in special file).

  +     

  +         if test -r /etc/.relid -a "X`uname -n`" = "X`uname -s`" ; then

  +             system=MP-RAS-`awk '{print $3}' /etc/.relid'`

  +         fi

  +         if test "`uname -s`" = "AIX" ; then

  +             system=AIX-`uname -v`.`uname -r`

  +         fi

  +     fi

  + fi

  + 

  + case $system in

  +     FreeBSD-*)

  + LIBS="$XLIBSW -lxpg4 $tk_oldLibs"

  + CFLAGS="$CFLAGS $X11_IMAKE_FLAGS"

  + AC_TRY_COMPILE([

  + #include <locale.h>

  + ], [

  + (void)setlocale(LC_ALL, "");

  + ], [

  + AC_MSG_RESULT(use xpg4 library.)

  + XLIBSW="$XLIBSW -lxpg4"

  + ], [

  + AC_MSG_RESULT(no need other libraries.)

  + ])

  + ;;

  +     *)

  + AC_MSG_RESULT(No additional library is needed.)

  + ;;

  + esac

  + 

  + CFLAGS=$tk_oldCflags

  + LIBS=$tk_oldLibs

  + 

  + #--------------------------------------------------------------------

    # The statements below define various symbols relating to creating

    # the stub'd version of the Tk library

    #

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

  *** 453,457 ****

    AC_SUBST(XINCLUDES)

    AC_SUBST(XLIBSW)

    AC_SUBST(TK_SHARED_BUILD)

  ! 

    AC_OUTPUT(Makefile tkConfig.sh)

  --- 563,567 ----

    AC_SUBST(XINCLUDES)

    AC_SUBST(XLIBSW)

    AC_SUBST(TK_SHARED_BUILD)

  ! AC_SUBST(X11_IMAKE_FLAGS)

    AC_OUTPUT(Makefile tkConfig.sh)

  *** generic/tkEvent.c.origThu Dec 16 22:57:36 1999

  --- generic/tkEvent.cThu Feb 24 22:16:07 2000

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

  *** 663,668 ****

  --- 663,680 ----

        }


    #ifdef TK_USE_INPUT_METHODS

  + #ifdef I18N_IMPROVE

  +       /*

  +        * No need to create an input context for each and every window.

  +        *

  +        * Futhermore, XFilterEvent() should be called just after the

  +        * event is fetched, since some IM server have protocol bugs that

  +        * causes Tk freezing, so events EXCEPT THE INPUT METHODS THINGS

  +        * should only be queued into Tcl event queue.

  +        *

  +        *m-hirano

  +        */

  + #else

        /*

         * Pass the event to the input method(s), if there are any, and

         * discard the event if the input method(s) insist.  Create the

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

  *** 684,689 ****

  --- 696,702 ----

        goto done;

    }

        }

  + #endif /* I18N_IMPROVE */

    #endif /* TK_USE_INPUT_METHODS */


        /*

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

  *** 936,941 ****

  --- 949,965 ----

        break;

    }

        }

  + 

  + #if defined(TK_USE_INPUT_METHODS) && defined(I18N_IMPROVE)

  +     if (eventPtr->type == KeyPress && eventPtr->xkey.keycode == 0) {

  +         /*

  +          * No doubt this is a composed message from IM server.

  +          * Tk can handle KeyPress event with zero keycode value 

  +          * if state of the event is zero.

  +          */

  +         eventPtr->xkey.state = 0;

  +     }

  + #endif /* TK_USE_INPUT_METHODS && I18N_IMPROVE */


        if ((dispPtr->delayedMotionPtr != NULL) && (position == TCL_QUEUE_TAIL)) {

    if ((eventPtr->type == MotionNotify) && (eventPtr->xmotion.window

  *** generic/tkInt.h.origFri Jan 21 04:54:41 2000

  --- generic/tkInt.hThu Feb 24 22:14:07 2000

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

  *** 26,31 ****

  --- 26,34 ----

    #ifndef _TKPORT

    #include <tkPort.h>

    #endif

  + #ifdef I18N_IMPROVE

  + #include <X11/Xlocale.h>

  + #endif /* I18N_IMPROVE */


    /*

     * Opaque type declarations:

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

  *** 499,504 ****

  --- 502,522 ----

        int warpX;

        int warpY;

        int useInputMethods;/* Whether to use input methods */

  + #ifdef TK_USE_INPUT_METHODS

  + #ifdef I18N_IMPROVE

  +     Tcl_Encoding imEncoding;/* Tcl encoding when the first Tcl

  +  * interp was created.

  +  * For encoding conversion from

  +  * XmbLookupString() to UTF.

  +  */

  +     XIC lastFocusedIC;/* The last focused input context on

  +  * the display.

  +  */

  + #ifdef XNDestroyCallback

  +     XIMCallback destroyCallback;

  + #endif /* XNDestroyCallback */

  + #endif /* I18N_IMPROVE */

  + #endif /* TK_USE_INPUT_METHODS */

    } TkDisplay;


    /*

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

  *** 999,1007 ****

    EXTERN intTk_WmCmd _ANSI_ARGS_((ClientData clientData,

        Tcl_Interp *interp, int argc, char **argv));


  - voidTkConsolePrint _ANSI_ARGS_((Tcl_Interp *interp,

  -     int devId, char *buffer, long size));

  - 

    EXTERN voidTkEventInit _ANSI_ARGS_((void));


    EXTERN intTkCreateMenuCmd _ANSI_ARGS_((Tcl_Interp *interp));

  --- 1017,1022 ----

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

  *** 1080,1085 ****

  --- 1095,1115 ----

     */

    EXTERN intTkUnsupported1Cmd _ANSI_ARGS_((ClientData clientData,

        Tcl_Interp *interp, int argc, char **argv));

  + 

  + #if defined(TK_USE_INPUT_METHODS) && defined(I18N_IMPROVE)

  + EXTERN XICTkpCreateIC _ANSI_ARGS_((TkWindow *winPtr));

  + EXTERN voidTkpDestroyIC _ANSI_ARGS_((TkWindow *winPtr, int needDestroy));

  + EXTERN intTk_ImconfigureObjCmd _ANSI_ARGS_((ClientData clientData,

  +     Tcl_Interp *interp, int objc,

  +     Tcl_Obj *CONST objv[]));

  + #endif

  + 

  + # undef TCL_STORAGE_CLASS

  + # define TCL_STORAGE_CLASS

  + 

  + EXTERN intTkConsoleInit _ANSI_ARGS_((Tcl_Interp *interp));

  + EXTERN voidTkConsolePrint _ANSI_ARGS_((Tcl_Interp *interp,

  +     int devId, char *buffer, long size));


    # undef TCL_STORAGE_CLASS

    # define TCL_STORAGE_CLASS DLLIMPORT

  *** generic/tkWindow.c.origThu Dec 16 22:57:36 1999

  --- generic/tkWindow.cThu Feb 24 22:21:05 2000

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

  *** 155,160 ****

  --- 155,163 ----

    #ifdef MAC_TCL

        {"unsupported1",TkUnsupported1Cmd,NULL,1, 1},

    #endif

  + #if defined(TK_USE_INPUT_METHODS) && defined(I18N_IMPROVE)

  +     {"imconfigure",NULL,Tk_ImconfigureObjCmd,1, 1},

  + #endif /* TK_USE_INPUT_METHODS && I18N_IMPROVE */

        {(char *) NULL,(int (*) _ANSI_ARGS_((ClientData, Tcl_Interp *, int, char **))) NULL, NULL, 0}

    };


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

  *** 209,214 ****

  --- 212,226 ----

        char *name));

    static voidOpenIM _ANSI_ARGS_((TkDisplay *dispPtr));

    static voidUnlinkWindow _ANSI_ARGS_((TkWindow *winPtr));

  + #ifdef TK_USE_INPUT_METHODS

  + #ifdef I18N_IMPROVE

  + static intCanInitiateIm _ANSI_ARGS_((void));

  + static voidIMInstantiateCallback _ANSI_ARGS_ ((Display *display,

  + XPointer clientData, XPointer callData));

  + static voidIMDestroyCallback _ANSI_ARGS_ ((XIM im, XPointer clientData, 

  + XPointer callData));

  + #endif /* I18N_IMPROVE */

  + #endif /* TK_USE_INPUT_METHODS */

    

    /*

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

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

  *** 1275,1281 ****

        TkBindDeadWindow(winPtr);

    #ifdef TK_USE_INPUT_METHODS

        if (winPtr->inputContext != NULL) {

  ! XDestroyIC(winPtr->inputContext);

        }

    #endif /* TK_USE_INPUT_METHODS */

        if (winPtr->tagPtr != NULL) {

  --- 1287,1297 ----

        TkBindDeadWindow(winPtr);

    #ifdef TK_USE_INPUT_METHODS

        if (winPtr->inputContext != NULL) {

  ! #ifdef I18N_IMPROVE

  ! TkpDestroyIC(winPtr, 1);

  ! #else

  !   XDestroyIC(winPtr->inputContext);

  ! #endif /* I18N_IMPROVE */

        }

    #endif /* TK_USE_INPUT_METHODS */

        if (winPtr->tagPtr != NULL) {

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

  *** 2427,2432 ****

  --- 2443,2623 ----

    {

        return ((TkWindow *) tkwin)->mainPtr->strictMotif;

    }

  + #ifdef TK_USE_INPUT_METHODS

  + #ifdef I18N_IMPROVE

  + 

  + static int

  + CanInitiateIm()

  + {

  +     static int inited = 0;

  +     static int ret = 0;

  +     char *locale;

  + 

  +     /*

  +      * Determine the current encoding from the LC_* or LANG environment

  +      * variables.  We previously used setlocale() to determine the locale,

  +      * but this does not work on some systems (e.g. Linux/i386 RH 5.0).

  +      */

  + 

  +     locale = getenv("LC_ALL");

  + 

  +     if (locale == NULL || locale[0] == '\0') {

  + locale = getenv("LC_CTYPE");

  +     }

  +     if (locale == NULL || locale[0] == '\0') {

  + locale = getenv("LANG");

  +     }

  +     if (locale == NULL || locale[0] == '\0') {

  + return False;

  +     }

  + 

  +     if (inited == 0) {

  + char *curSpec = setlocale(LC_ALL, NULL);

  + 

  + inited = 1;

  + 

  + if (strcmp(locale, "C") == 0 ||

  +     strcmp(locale, "POSIX") == 0) {

  +     goto Checked;

  + }

  + 

  + /*

  +  * Ok I know, everyone of core Tcl/Tk developer hates this.

  +  * believe it or not, it must be needed to call

  +  * setlocale(3)/_Xsetlocale() VERY HERE. This is what the X

  +  * input method wants.

  +  * Note that X11's i18n implementation should be ONLY governed

  +  * by LC_CTYPE. This is clearly/explicitly specified in X11

  +  * documente Chapter 13. Thus, If there are some X11

  +  * implementation that need using LC_ALL to initialize i18n

  +  * subsystem, I won't care about such a X library.

  +  * But, we are still on edge of darkside. ctype(3) routines

  +  * are governed by LC_CTYPE.... Need to create "Locale

  +  * independent ctype libraries" for Tcl/Tk...

  +  *

  +  *m-hirano

  +  */

  + 

  + /*

  +  * OK, First of all, setting WHOLE locale to "C".

  +  */

  + (void)setlocale(LC_ALL, "C");

  + if (setlocale(LC_CTYPE, locale) == NULL) {

  +     /*

  +      * Reset to old locale.

  +      */

  +     if (setlocale(LC_ALL, curSpec) == NULL) {

  + (void)setlocale(LC_ALL, "C");

  +     }

  +     goto Checked;

  + } else {

  +     /*

  +      * For insurance, reset LC_NUMERIC to "C" for Tcl numeric parsing.

  +      */

  +     (void)setlocale(LC_NUMERIC, "C");

  + }

  + if (XSupportsLocale() != True) {

  +     goto Checked;

  + }

  + 

  + ret = True;

  + /*

  +  * At last, Setting the locale modifiers.

  +  */

  + (void)XSetLocaleModifiers("");

  +     }

  + 

  +     Checked:

  +     return ret;

  + }

  + 

  + /*

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

  +  *

  +  * IMInstantiateCallback

  +  *

  +  *Whenever IM server become available, this function will be called.

  +  *

  +  * Results:

  +  *OpenIM() is called.

  +  *

  +  * Side effects:

  +  *None.

  +  *

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

  +  */

  + 

  + void

  + IMInstantiateCallback(display, clientData, callData)

  +      Display *display;

  +      XPointer clientData;

  +      XPointer callData;

  + {

  +     TkDisplay *dispPtr = (TkDisplay *)clientData;

  + 

  +     if (display == dispPtr->display &&

  + dispPtr->inputMethod == NULL) {

  + OpenIM(dispPtr);

  +     }

  + }

  + 

  + /*

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

  +  *

  +  * IMDestroyCallback

  +  *

  +  *Whenever IM server stops the service, this function will be called.

  +  *

  +  * Results:

  +  *the XIM opened before is marked as unusable.

  +  *

  +  * Side effects:

  +  *XIC using this XIM will be useless.

  +  *

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

  +  */

  + void

  + IMDestroyCallback(im, clientData, callData)

  +      XIM im;

  +      XPointer clientData;

  +      XPointer callData;

  + {

  +     TkDisplay *dispPtr = (TkDisplay *)clientData;

  +     if (im == dispPtr->inputMethod) {

  + Tcl_HashTable winTable = dispPtr->winTable;

  + Tcl_HashEntry *entry = NULL;

  + Tcl_HashSearch search;

  + TkWindow *winPtr;

  + 

  + /*

  +  * We must not call XCloseIM() or XDestroyIC().

  +  * because the XIM and XIC are destroyed by Xlib 

  +  * automatically.

  +  */

  + for (entry = Tcl_FirstHashEntry(&winTable, &search); entry != NULL;

  +      entry = Tcl_NextHashEntry(&search)) {

  +     winPtr = (TkWindow *)Tcl_GetHashValue(entry);

  +     if (winPtr->dispPtr->display == dispPtr->display &&

  + winPtr->dispPtr->inputMethod == im &&

  + winPtr->inputContext != NULL) {

  + TkpDestroyIC(winPtr, 0);

  +     }

  + }

  + dispPtr->inputMethod = NULL;

  + dispPtr->lastFocusedIC = NULL;

  + #ifdef HAVE_XIMREGINSTCB

  + #ifdef NO_XIDPROC

  + XRegisterIMInstantiateCallback(dispPtr->display, NULL, NULL, NULL,

  +        (XIMProc)IMInstantiateCallback, (XPointer *)dispPtr);

  + #else

  + XRegisterIMInstantiateCallback(dispPtr->display, NULL, NULL, NULL,

  +        (XIDProc)IMInstantiateCallback, (XPointer)dispPtr);

  + #endif /* NO_XIDPROC */

  + #endif /* HAVE_XIMREGINSTCB */

  +     }

  + }

  + #endif /* I18N_IMPROVE */

  + #endif /* TK_USE_INPUT_METHODS */

    

    /* 

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

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

  *** 2457,2464 ****

  --- 2648,2681 ----

        unsigned short i;

        XIMStyles *stylePtr;


  + #ifdef I18N_IMPROVE

  +     int styleFound = 0;

  + 

  +     dispPtr->inputMethod = NULL;

  +     dispPtr->imEncoding = NULL;

  +     dispPtr->lastFocusedIC = NULL;

  + 

  +     if (CanInitiateIm() == False) {

  + return;

  +     }

  + #endif /* I18N_IMPROVE */

        dispPtr->inputMethod = XOpenIM(dispPtr->display, NULL, NULL, NULL);

        if (dispPtr->inputMethod == NULL) {

  + #ifdef I18N_IMPROVE

  + #ifdef HAVE_XIMREGINSTCB

  + /*

  +  * Maybe no IM server is available right now.

  +  * Try to register instantiate callback.

  +  */

  + #ifdef NO_XIDPROC

  + XRegisterIMInstantiateCallback(dispPtr->display, NULL, NULL, NULL,

  +        (XIMProc)IMInstantiateCallback, (XPointer *)dispPtr);

  + #else

  + XRegisterIMInstantiateCallback(dispPtr->display, NULL, NULL, NULL,

  +        (XIDProc)IMInstantiateCallback, (XPointer)dispPtr);

  + #endif /* NO_XIDPROC */

  + #endif /* HAVE_XIMREGINSTCB */

  + #endif /* I18N_IMPROVE */

    return;

        }


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

  *** 2469,2479 ****

        for (i = 0; i < stylePtr->count_styles; i++) {

    if (stylePtr->supported_styles[i]

    == (XIMPreeditNothing|XIMStatusNothing)) {

  !     XFree(stylePtr);

  !     return;

    }

        }

        XFree(stylePtr);


        error:


  --- 2686,2715 ----

        for (i = 0; i < stylePtr->count_styles; i++) {

    if (stylePtr->supported_styles[i]

    == (XIMPreeditNothing|XIMStatusNothing)) {

  ! #ifdef I18N_IMPROVE

  !     styleFound = 1;

  ! #else

  !       XFree(stylePtr);

  !       return;

  ! #endif /* I18N_IMPROVE */

    }

        }

        XFree(stylePtr);

  + #ifdef I18N_IMPROVE

  +     if (styleFound == 1) {

  + /*

  +  * Create a Tcl_Encoding for XmbLookupString() conversion.

  +  */

  + dispPtr->imEncoding = Tcl_GetEncoding(NULL, Tcl_GetEncodingName(NULL));

  + #ifdef XNDestroyCallback

  + dispPtr->destroyCallback.client_data = (XPointer)dispPtr;

  + dispPtr->destroyCallback.callback = (XIMProc)IMDestroyCallback;

  + (void)XSetIMValues(dispPtr->inputMethod,

  +    XNDestroyCallback, &(dispPtr->destroyCallback), NULL);

  + #endif /* XNDestroyCallback */

  + return;

  +     }

  + #endif /* I18N_IMPROVE */


        error:


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

  *** 2714,2719 ****

  --- 2950,2956 ----

        Tcl_DString class;

        ThreadSpecificData *tsdPtr;


  + 

        /*

         * Ensure that we are getting the matching version of Tcl.  This is

         * really only an issue when Tk is loaded dynamically.

  *** unix/Makefile.in.origThu Feb 10 12:11:01 2000

  --- unix/Makefile.inThu Feb 24 22:25:33 2000

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

  *** 211,217 ****

    # modify any of this stuff by hand.

    #----------------------------------------------------------------


  ! AC_FLAGS =@EXTRA_CFLAGS@ @DEFS@

    RANLIB =@RANLIB@

    SRC_DIR =@srcdir@/..

    TOP_DIR =@srcdir@/..

  --- 211,218 ----

    # modify any of this stuff by hand.

    #----------------------------------------------------------------


  ! AC_FLAGS =@EXTRA_CFLAGS@ @DEFS@ @X11_IMAKE_FLAGS@ \

  ! -DI18N_IMPROVE @CPPFLAGS@

    RANLIB =@RANLIB@

    SRC_DIR =@srcdir@/..

    TOP_DIR =@srcdir@/..

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

  *** 268,274 ****

    tkUnixCursor.o tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o \

    tkUnixFocus.o tkUnixFont.o tkUnixInit.o tkUnixKey.o tkUnixMenu.o \

    tkUnixMenubu.o tkUnixScale.o tkUnixScrlbr.o tkUnixSelect.o \

  ! tkUnixSend.o tkUnixWm.o tkUnixXId.o tkStubInit.o tkStubLib.o


    STUB_LIB_OBJS = tkStubLib.o tkStubImg.o


  --- 269,276 ----

    tkUnixCursor.o tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o \

    tkUnixFocus.o tkUnixFont.o tkUnixInit.o tkUnixKey.o tkUnixMenu.o \

    tkUnixMenubu.o tkUnixScale.o tkUnixScrlbr.o tkUnixSelect.o \

  ! tkUnixSend.o tkUnixWm.o tkUnixXId.o tkStubInit.o tkStubLib.o \

  ! tkUnixIm.o


    STUB_LIB_OBJS = tkStubLib.o tkStubImg.o


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

  *** 330,335 ****

  --- 332,338 ----

    $(UNIX_DIR)/tkUnixEmbed.c $(UNIX_DIR)/tkUnixEvent.c \

    $(UNIX_DIR)/tkUnixFocus.c \

    $(UNIX_DIR)/tkUnixFont.c $(UNIX_DIR)/tkUnixInit.c \

  + $(UNIX_DIR)/tkUnixIm.c \

    $(UNIX_DIR)/tkUnixKey.c \

    $(UNIX_DIR)/tkUnixMenu.c $(UNIX_DIR)/tkUnixMenubu.c \

    $(UNIX_DIR)/tkUnixScale.c $(UNIX_DIR)/tkUnixScrlbr.c \

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

  *** 843,848 ****

  --- 846,854 ----


    tkUnixFont.o: $(UNIX_DIR)/tkUnixFont.c

    $(CC) -c $(CC_SWITCHES) $(UNIX_DIR)/tkUnixFont.c

  + 

  + tkUnixIm.o: $(UNIX_DIR)/tkUnixIm.c

  + $(CC) -c $(CC_SWITCHES) $(UNIX_DIR)/tkUnixIm.c


    tkUnixInit.o: $(UNIX_DIR)/tkUnixInit.c $(GENERIC_DIR)/tkInitScript.h tkConfig.sh

    $(CC) -c $(CC_SWITCHES) -DTK_LIBRARY=\"${TK_LIBRARY}\" \

  *** unix/tkConfig.sh.in.origThu Feb 10 12:11:02 2000

  --- unix/tkConfig.sh.inThu Feb 24 22:14:08 2000

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

  *** 20,26 ****

    TK_PATCH_LEVEL='@TK_PATCH_LEVEL@'


    # -D flags for use with the C compiler.

  ! TK_DEFS='@DEFS@'


    # Flag, 1: we built a shared lib, 0 we didn't

    TK_SHARED_BUILD=@TK_SHARED_BUILD@

  --- 20,26 ----

    TK_PATCH_LEVEL='@TK_PATCH_LEVEL@'


    # -D flags for use with the C compiler.

  ! TK_DEFS='@DEFS@ @X11_IMAKE_FLAGS@ -DI18N_IMPROVE'


    # Flag, 1: we built a shared lib, 0 we didn't

    TK_SHARED_BUILD=@TK_SHARED_BUILD@

  *** unix/tkUnixEvent.c.origFri Apr 16 03:51:46 1999

  --- unix/tkUnixEvent.cThu Feb 24 22:14:08 2000

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

  *** 161,167 ****

            (void) XSync(dispPtr->display, False);

            (void) XCloseDisplay(dispPtr->display);

        }

  !     

        ckfree((char *) dispPtr);

    }

    

  --- 161,172 ----

            (void) XSync(dispPtr->display, False);

            (void) XCloseDisplay(dispPtr->display);

        }

  ! #ifdef I18N_IMPROVE

  !     if (displayPtr->imEncoding != NULL) {

  ! Tcl_FreeEncoding(displayPtr->imEncoding);

  !     }

  ! #endif /* I18N_IMPROVE */    

  ! 

        ckfree((char *) dispPtr);

    }

    

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

  *** 246,251 ****

  --- 251,268 ----


        while (numFound > 0) {

    XNextEvent(display, &event);

  + #ifdef I18N_IMPROVE

  + /*

  +  * To avoid Tk freezing by IM server's protocol bugs,

  +  * Re-check queued event after an event is filterd.

  +  *

  +  *m-hirano

  +  */

  + if (XFilterEvent(&event, None) == True) {

  +     numFound = XEventsQueued(display, QueuedAlready);

  +     continue;

  + }

  + #endif /* I18N_IMPROVE */

    Tk_QueueWindowEvent(&event, TCL_QUEUE_TAIL);

    numFound--;

        }

  *** unix/tkUnixIm.c.origThu Feb 24 22:14:08 2000

  --- unix/tkUnixIm.cThu Feb 24 22:14:08 2000

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

  *** 0 ****

  --- 1,255 ----

  + /* 

  +  * tkUnixIm.c --

  +  *

  +  *      This file contains modules to implement the XIM protocol session.

  +  *This is the shrinked version of tkXIM.c, worte for tk8.0jp.

  +  *

  +  *Author:m-hirano@sra.co.jp

  +  *

  +  * Copyright 1999 Software Research Associates, Inc.

  +  *

  +  * Permission to use, copy, modify, and distribute this software and its

  +  * documentation for any purpose and without fee is hereby granted, provided

  +  * that the above copyright notice appear in all copies and that both that

  +  * copyright notice and this permission notice appear in supporting

  +  * documentation, and that the name of Software Research Associates not be

  +  * used in advertising or publicity pertaining to distribution of the

  +  * software without specific, written prior permission.  Software Research

  +  * Associates makes no representations about the suitability of this software

  +  * for any purpose.  It is provided "as is" without express or implied

  +  * warranty.

  +  */

  + 

  + #if 0

  + static char rcsid[] = "$Header: /home/m-hirano/cvsroot/tcltk/tk8.1/unix/tkUnixIm.c,v 1.1 1999/05/10 00:39:16 m-hirano Exp $";

  + #endif

  + 

  + #include "tkPort.h"

  + #include "tkInt.h"

  + 

  + #ifdef TK_USE_INPUT_METHODS

  + #ifdef I18N_IMPROVE

  + 

  + static voidTkpIMGenericHandler _ANSI_ARGS_((ClientData clientData, XEvent *eventPtr));

  + static TkWindow *GetToplevel _ANSI_ARGS_((TkWindow *winPtr));

  + static voidTkpCreateIMGenericHandler _ANSI_ARGS_((Tk_Window tkwin));

  + static voidTkpDeleteIMGenericHandler _ANSI_ARGS_((Tk_Window tkwin));

  + 

  + static TkWindow *

  + GetToplevel(winPtr)

  +      TkWindow *winPtr;

  + {

  +     while (!(winPtr->flags & TK_TOP_LEVEL)) {

  + winPtr = winPtr->parentPtr;

  + if (winPtr == NULL) {

  +     return NULL;

  + }

  +     }

  +     return winPtr;

  + }

  + 

  + 

  + static void

  + TkpIMGenericHandler(clientData, eventPtr)

  +      ClientData clientData;

  +      XEvent *eventPtr;

  + {

  +     Tk_Window tkwin = (Tk_Window)clientData;

  +     TkWindow *winPtr = (TkWindow *)clientData;

  +     

  +     if (eventPtr->xany.window != Tk_WindowId(tkwin) ||

  + winPtr->inputContext == NULL ||

  + !(winPtr->flags & TK_CHECKED_IC)) {

  + /*

  +  * Why ME ???

  +  */

  + return;

  +     }

  + 

  +     /*

  +      * Well, should I care about Enter/Leave ?

  +      */

  + 

  +     switch (eventPtr->type) {

  +         case KeyPress:

  +         case FocusIn: {

  +     Window root, child;

  +     int rootX, rootY;

  +     int wX, wY;

  +     unsigned int mask;

  + 

  +     /*

  +      * Care about case mouse pointer is not on winPtr->window.

  +      * In such a case, IM server can't fetch any events from Tk.

  +      */

  + 

  +     if (XQueryPointer(winPtr->display,

  +       RootWindow(winPtr->display, winPtr->screenNum),

  +       &root, &child, &rootX, &rootY, &wX, &wY, &mask) == True) {

  + TkWindow *pWin = (TkWindow *)Tk_CoordsToWindow(rootX, rootY,

  +        (Tk_Window)winPtr);

  + if (pWin != NULL && (pWin->window != winPtr->window)) {

  + #if 0

  +     /*

  +      * Code belows are what I REALLY want to do. But,

  +      * in XIMPreeditPosition mode, IM server use the

  +      * focus window as key event source window and as

  +      * PreeditArea window by X11 specification. I want

  +      * IM server to use this focus window ONLY as key

  +      * event source. Means:

  +      *

  +      * o PreeditArea and PreeditPosition take place

  +      *   within client window (winPtr->window).

  +      *o KeyPress event source is the window in which

  +      *  mouse pointer is (pWin->window).

  +      */

  + 

  +     if (XSetICValues(winPtr->inputContext, XNFocusWindow,

  +      pWin->window, NULL) != NULL) {

  + fprintf(stderr, "debugIC: can't set IC focus to pointer window 0x%08x\n",

  + pWin->window);

  +     } else {

  + fprintf(stderr, "debugIC: set IC focus to pointer window 0x%08x\n",

  + pWin->window);

  +     }

  + #endif

  +     /*

  +      * Check pWin and winPtr are in same toplevel.

  +      * If they are NOT, don't change focus. 

  +      */

  +     TkWindow *pTop = GetToplevel(pWin);

  +     TkWindow *wTop = GetToplevel(winPtr);

  +     if (pTop == wTop) {

  + TkpChangeFocus(winPtr, 1);

  +     }

  + }

  +     }

  +     /*

  +      * Get current focused window.

  +      */

  +     if (winPtr->dispPtr->lastFocusedIC != winPtr->inputContext) {

  + winPtr->dispPtr->lastFocusedIC = winPtr->inputContext;

  + XSetICFocus(winPtr->inputContext);

  +     }

  +     break;

  + }

  + 

  +         case FocusOut: {

  +     winPtr->dispPtr->lastFocusedIC = None;

  +     XUnsetICFocus(winPtr->inputContext);

  +     break;

  + }

  + 

  + case DestroyNotify: {

  +     winPtr->dispPtr->lastFocusedIC = NULL;

  +     XUnsetICFocus(winPtr->inputContext);

  +     TkpDeleteIMGenericHandler(tkwin);

  +     break;

  + }

  +     }

  + }

  + 

  + 

  + static void

  + TkpCreateIMGenericHandler(tkwin)

  +      Tk_Window tkwin;

  + {

  +     Tk_CreateEventHandler(tkwin, FocusChangeMask|StructureNotifyMask|KeyPressMask

  + #if 0

  +   EnterWindowMask|LeaveWindowMask,

  + #else

  +   ,

  + #endif

  +   (Tk_EventProc *)TkpIMGenericHandler,

  +   (ClientData)tkwin);

  + }

  + 

  + 

  + static void

  + TkpDeleteIMGenericHandler(tkwin)

  +      Tk_Window tkwin;

  + {

  +     Tk_DeleteEventHandler(tkwin, FocusChangeMask|StructureNotifyMask|KeyPressMask

  + #if 0

  +   EnterWindowMask|LeaveWindowMask,

  + #else

  +   ,

  + #endif

  +   (Tk_EventProc *)TkpIMGenericHandler,

  +   (ClientData)tkwin);

  + }

  + 

  + 

  + XIC

  + TkpCreateIC(winPtr)

  +      TkWindow *winPtr;

  + {

  +     if (winPtr->dispPtr->inputMethod != NULL &&

  + !(winPtr->flags & TK_CHECKED_IC)) {

  + winPtr->inputContext =

  + XCreateIC(winPtr->dispPtr->inputMethod,

  +   XNInputStyle, XIMPreeditNothing|XIMStatusNothing,

  +   XNClientWindow, winPtr->window,

  +   XNFocusWindow, winPtr->window,

  +   NULL);

  + if (winPtr->inputContext != NULL) {

  +     TkpCreateIMGenericHandler((Tk_Window)winPtr);

  + }

  +     }

  +     winPtr->flags |= TK_CHECKED_IC;

  +     return winPtr->inputContext;

  + }

  + 

  + 

  + void

  + TkpDestroyIC(winPtr, needDestroy)

  +      TkWindow *winPtr;

  +      int needDestroy;

  + {

  +     TkpDeleteIMGenericHandler((Tk_Window)winPtr);

  +     if (winPtr->inputContext == winPtr->dispPtr->lastFocusedIC) {

  + winPtr->dispPtr->lastFocusedIC = None;

  +     }

  +     if (needDestroy == 1 &&

  + winPtr->inputContext != NULL) {

  + XDestroyIC(winPtr->inputContext);

  +     }

  +     winPtr->flags &= ~(TK_CHECKED_IC);

  +     winPtr->inputContext = NULL;

  + }

  + 

  + 

  + int

  + Tk_ImconfigureObjCmd(clientData, interp, objc, objv)

  +      ClientData clientData;/* Main window associated with

  +  * interpreter. */

  +      Tcl_Interp *interp;/* Current interpreter. */

  +      int objc;/* Number of arguments. */

  +      Tcl_Obj *CONST objv[];/* Argument objects. */

  + {

  +     Tk_Window tkwin = (Tk_Window)clientData;

  +     Tcl_Obj *resultPtr = Tcl_GetObjResult(interp);

  + 

  +     if (objc < 2) {

  + Tcl_WrongNumArgs(interp, 1, objv, "path ?option? ?arg? ...");

  + return TCL_ERROR;

  +     }

  + 

  +     tkwin = Tk_NameToWindow(interp, Tcl_GetStringFromObj(objv[1], NULL), tkwin);

  +     if (tkwin == NULL) {

  + return TCL_ERROR;

  +     }

  + 

  +     if (((TkWindow *)tkwin)->dispPtr->inputMethod == NULL) {

  + Tcl_AppendStringsToObj(resultPtr, "No IM server is available.", NULL);

  + return TCL_ERROR;

  +     }

  + 

  +     Tcl_AppendStringsToObj(resultPtr,

  +   (TkpCreateIC((TkWindow *)tkwin) != NULL) ? "1" : "0",

  +   NULL);

  +     return TCL_OK;

  + }

  + 

  + #endif /* I18N_IMPROVE */

  + #endif /* TK_USE_INPUT_METHODS */

  *** unix/tkUnixKey.c.origWed Feb  9 03:13:54 2000

  --- unix/tkUnixKey.cThu Feb 24 22:14:08 2000

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

  *** 89,95 ****

  --- 89,100 ----

    #endif /* TK_USE_INPUT_METHODS */

        Tcl_DStringSetLength(&buf, len);


  + #if defined(I18N_IMPROVE) && defined(TK_USE_INPUT_METHODS)

  +     Tcl_ExternalToUtfDString(winPtr->dispPtr->imEncoding,

  +      Tcl_DStringValue(&buf), len, dsPtr);

  + #else

        Tcl_ExternalToUtfDString(NULL, Tcl_DStringValue(&buf), len, dsPtr);

  + #endif /* I18N_IMPROVE && TK_USE_INPUT_METHODS */

        Tcl_DStringFree(&buf);


        return Tcl_DStringValue(dsPtr);

  *** library/entry.tcl.origThu Jan  6 03:22:24 2000

  --- library/entry.tclThu Feb 24 21:13:57 2000

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

  *** 214,219 ****

  --- 214,226 ----

        }

    }


  + # input method configuration binding (unix only)

  + if {![string compare $tcl_platform(platform) "unix"]} {

  +     if {[string compare [info commands imconfigure] {}]} {

  + bind Entry <FocusIn> {catch {imconfigure %W}}

  +     }

  + }

  + 

    # Additional emacs-like bindings:


    bind Entry <Control-a> {

  *** library/text.tcl.origThu Feb 10 09:52:50 2000

  --- library/text.tclThu Feb 24 21:13:57 2000

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

  *** 378,383 ****

  --- 378,390 ----

        }

    }


  + # UNIX only bindings:

  + 

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

  + [string compare [info commands imconfigure] {}]} {

  +     bind Text <FocusIn> {catch {imconfigure %W}}

  + }

  + 

    # Macintosh only bindings:


    # if text black & highlight black -> text white, other text the same


  PatchFiles:

  configure.in tkEvent.c tkInt.h tkWindow.c Makefile.in tkConfig.sh

      tkUnixEvent.c tkUnixIm.c (new file) tkUnixKey.c entry.tcl text.tcl


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

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

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

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

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


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

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

   Following URL explains more details about Windows 2000 logo certification:

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

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

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

   Moo Kim
   


tkt_uuid: 736371ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: None
title: _XInitImageFuncPtrs - undocumented function
comment:
  _XInitImageFuncPtrs is not documented, nor an official
  xlib function.

  This link points out the LSB discussion on whether to
  include this function:

  http://sourceforge.net/tracker/index.php?func=detail&aid=567489&group_id=1107&atid=101107

  It looks like it relates to running tcl on a machine of
  one endiannes, and  displaying it on a different
  endianness machine.  Before eliminating it, I suppose
  it would be wise to run some tests in these circumstances.

  Should the function itself prove necessary... since the
  endianness check in C is probably faster than doing a
  lookup on the Tcl variable, maybe Tcl should have a C
  interface to this test, which could be used in both
  places - here, as well as the place where the tcl
  variable is set.


tkt_uuid: 220409ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Can't select fast-drawing (width 0) canvas lines
comment:
  OriginalBugID: 925 Bug
  Version: 8.0.4
  SubmitDate: '1998-12-04'
  LastModified: '1999-02-03'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: stanton
  OS: Other
  Machine: NA
  FixedDate: '1999-02-03'
  FixedInVersion: 8.0.5


  Name:

  Sebastian Wangnick


  ReproducibleScript:

  Try the following wish script:


  canvas .c -closeenough 0; pack .c

  .c create line 30 50 170 50

  .c create line 30 100 170 100 -width 0

  .c bind all <Button-1> {puts Gotcha}


  ObservedBehavior:

  The first and the second line look equal, width 0 indicating fast-drawing mode.


  However, you wont be able to select the second line!


  Patch:

  diff -brc ../tk8.0.4.orig/generic/tkCanvLine.c ./generic/tkCanvLine.c

  *** ../tk8.0.4.orig/generic/tkCanvLine.cMon Sep 14 18:23:05 1998

  --- ./generic/tkCanvLine.cWed Dec  2 07:31:14 1998

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

  *** 814,820 ****

        double *coordPtr, *linePoints;

        double staticSpace[2*MAX_STATIC_POINTS];

        double poly[10];

  !     double bestDist, dist;

        int numPoints, count;

        int changedMiterToBevel;/* Non-zero means that a mitered corner

     * had to be treated as beveled after all

  --- 814,820 ----

        double *coordPtr, *linePoints;

        double staticSpace[2*MAX_STATIC_POINTS];

        double poly[10];

  !     double bestDist, dist, width;

        int numPoints, count;

        int changedMiterToBevel;/* Non-zero means that a mitered corner

     * had to be treated as beveled after all

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

  *** 843,848 ****

  --- 843,853 ----

    linePoints = linePtr->coordPtr;

        }


  +     width = (double) linePtr->width;

  +     if (width < 1.0) {

  + width = 1.0;

  +     }

  + 

        /*

         * The overall idea is to iterate through all of the edges of

         * the line, computing a polygon for each edge and testing the

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

  *** 863,869 ****

    || ((linePtr->joinStyle == JoinRound)

    && (count != numPoints))) {

        dist = hypot(coordPtr[0] - pointPtr[0], coordPtr[1] - pointPtr[1])

  !     - linePtr->width/2.0;

        if (dist <= 0.0) {

    bestDist = 0.0;

    goto done;

  --- 868,874 ----

    || ((linePtr->joinStyle == JoinRound)

    && (count != numPoints))) {

        dist = hypot(coordPtr[0] - pointPtr[0], coordPtr[1] - pointPtr[1])

  !     - width/2.0;

        if (dist <= 0.0) {

    bestDist = 0.0;

    goto done;

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

  *** 879,885 ****

     */


    if (count == numPoints) {

  !     TkGetButtPoints(coordPtr+2, coordPtr, (double) linePtr->width,

        linePtr->capStyle == CapProjecting, poly, poly+2);

    } else if ((linePtr->joinStyle == JoinMiter) && !changedMiterToBevel) {

        poly[0] = poly[6];

  --- 884,890 ----

     */


    if (count == numPoints) {

  !     TkGetButtPoints(coordPtr+2, coordPtr, width,

        linePtr->capStyle == CapProjecting, poly, poly+2);

    } else if ((linePtr->joinStyle == JoinMiter) && !changedMiterToBevel) {

        poly[0] = poly[6];

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

  *** 887,893 ****

        poly[2] = poly[4];

        poly[3] = poly[5];

    } else {

  !     TkGetButtPoints(coordPtr+2, coordPtr, (double) linePtr->width, 0,

        poly, poly+2);


        /*

  --- 892,898 ----

        poly[2] = poly[4];

        poly[3] = poly[5];

    } else {

  !     TkGetButtPoints(coordPtr+2, coordPtr, width, 0,

        poly, poly+2);


        /*

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

  *** 911,927 ****

        }

    }

    if (count == 2) {

  !     TkGetButtPoints(coordPtr, coordPtr+2, (double) linePtr->width,

        linePtr->capStyle == CapProjecting, poly+4, poly+6);

    } else if (linePtr->joinStyle == JoinMiter) {

        if (TkGetMiterPoints(coordPtr, coordPtr+2, coordPtr+4,

  !     (double) linePtr->width, poly+4, poly+6) == 0) {

    changedMiterToBevel = 1;

  ! TkGetButtPoints(coordPtr, coordPtr+2, (double) linePtr->width,

    0, poly+4, poly+6);

        }

    } else {

  !     TkGetButtPoints(coordPtr, coordPtr+2, (double) linePtr->width, 0,

        poly+4, poly+6);

    }

    poly[8] = poly[0];

  --- 916,932 ----

        }

    }

    if (count == 2) {

  !     TkGetButtPoints(coordPtr, coordPtr+2, width,

        linePtr->capStyle == CapProjecting, poly+4, poly+6);

    } else if (linePtr->joinStyle == JoinMiter) {

        if (TkGetMiterPoints(coordPtr, coordPtr+2, coordPtr+4,

  !     width, poly+4, poly+6) == 0) {

    changedMiterToBevel = 1;

  ! TkGetButtPoints(coordPtr, coordPtr+2, width,

    0, poly+4, poly+6);

        }

    } else {

  !     TkGetButtPoints(coordPtr, coordPtr+2, width, 0,

        poly+4, poly+6);

    }

    poly[8] = poly[0];

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

  *** 942,948 ****


        if (linePtr->capStyle == CapRound) {

    dist = hypot(coordPtr[0] - pointPtr[0], coordPtr[1] - pointPtr[1])

  ! - linePtr->width/2.0;

    if (dist <= 0.0) {

        bestDist = 0.0;

        goto done;

  --- 947,953 ----


        if (linePtr->capStyle == CapRound) {

    dist = hypot(coordPtr[0] - pointPtr[0], coordPtr[1] - pointPtr[1])

  ! - width/2.0;

    if (dist <= 0.0) {

        bestDist = 0.0;

        goto done;

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

  *** 1015,1020 ****

  --- 1020,1026 ----

        LineItem *linePtr = (LineItem *) itemPtr;

        double staticSpace[2*MAX_STATIC_POINTS];

        double *linePoints;

  +     double width;

        int numPoints, result;


        /*

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

  *** 1042,1049 ****

         * Check the segments of the line.

         */


        result = TkThickPolyLineToArea(linePoints, numPoints, 

  !     (double) linePtr->width, linePtr->capStyle, linePtr->joinStyle,

        rectPtr);

        if (result == 0) {

    goto done;

  --- 1048,1060 ----

         * Check the segments of the line.

         */


  +     width = (double) linePtr->width;

  +     if (width < 1.0) {

  + width = 1.0;

  +     }

  + 

        result = TkThickPolyLineToArea(linePoints, numPoints, 

  !     width, linePtr->capStyle, linePtr->joinStyle,

        rectPtr);

        if (result == 0) {

    goto done;


  PatchFiles:

  tkCanvLine.c




  Note that this patch is also available for Tk8.0p2 at http://www.scriptics.com/resource/software/patches/tk80p2.


tkt_uuid: 601518ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 67. Unix Window Operations
priority: 8
foundin: None
resolution: Accepted
title: Fix the two-second raise delay
comment:
  The attached patch fixes the longstanding two second
  "raise delay" seen under certain window managers, by
  making [raise] and [lower] asynchronous.

  A forthcoming TIP describes the changes in detail; for
  now see
  <URL: http://www.flightlab.com/~joe/tcl/raise-delay.txt
  >


tkt_uuid: 220498ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 2
foundin: obsolete: 8.0.4
resolution: Fixed
title: Font selection fails for some X servers
comment:
  OriginalBugID: 1808 RFE
  Version: 8.0.4
  SubmitDate: '1999-04-14'
  LastModified: '2000-02-25'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Linux-Red Hat
  Machine: Other
  FixedDate: '2000-02-25'
  FixedInVersion: 8.1.1


  Name:
  D. Richard Hipp

  ReproducibleScript:
  # Fails on the KEA-X! Xserver.  Works OK on XFree86.
      #
      button .b -text hello -font "times 24"; pack .b

  ObservedBehavior:
  On KEA-X! (An X server for Win98) any font named using "<family> <size>"
      gives you the font we normally call "fixed".
      
      I traced the problem to the XLoadQueryFont() call within
      TkpGetNativeFont() in the file unix/tkUnixFont.c.  KEA-X! always
      returns a font for this call.  It never returns NULL.  If it can
      do no better, it returns the fixed-pitch font.  
      
      I can think of several work-arounds here, but in every case
      I think I need to patch the core.  I'd like to have a
      discussion with your developers about what the best solution
      might be.  I'll be happy to implement a fix and submit it
      to you, once we decide what the best approach is.  But I
      need your input.  Please call.  D. Richard Hipp.  704.948.4565

  DesiredBehavior:
  When I request "times 24", I expect to see a 24-point Times font,
      or at least something close to that.



  This is really the fault of the Xserver (Exceed has the same problem,
  but Xwin32 works as expected).  The X server is not supposed to
  substitute a font for you (and Unix X servers adhere to this).  The
  Windows X servers should follow this standard, but some choose the
  "Windows" way of returning a default font. 
  -- 02/25/2000 hobbs
  IN RESPONSE:
  I agree.  But the fact remains that the only X server many
  folks will ever see is Exceed and we want to give them
  a good experience.

  This bug has been fixed for ages, by the way.  I think
  it was fixed in like 8.1 or something.
  -- 
  D. Richard Hipp -- drh@acm.org -- http://www.hwaci.com/drh/ 
  -- 02/25/2000 hobbs


tkt_uuid: 535350ffffffffffffffffffffffffffffffffff
type: Patch
status: Deleted
subsystem: None
priority: 5 Medium
foundin: None
resolution: Works For Me
title: bgerror - wrong displaying window
comment:
  Hi,

  my problem is that: Vhen is invoked "bgerror",
  created window is separated from its content.

  URL of screenshots is:

  http://web.telecom.cz/WoodPrint/brerror1.png
  http://web.telecom.cz/WoodPrint/brerror2.png
  and after move window vith mouse
  http://web.telecom.cz/WoodPrint/brerror3.png

  Content of window is stiky on sceen and I dosenot
  move it.

  I found "woraround?", to comment line 245 
  in file bgerror.tcl

      set y [expr {([winfo screenheight .bgerrorDialog] -
  $height)/2 - \
              [winfo vrooty $parent]}]
      .bgerrorDialog configure -width $width
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      wm geometry .bgerrorDialog +$x+$y
      wm deiconify .bgerrorDialog

  OR execute it later

  after 1 .bgerrorDialog configure -width $width

  after this things work fine.

  Tanks for comments Michal <wohnivec@iol.cz>


tkt_uuid: 220678ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 2
foundin: obsolete: 8.2.1
resolution: Fixed
title: Letters "a","m","T" display in incorrect font
comment:
  OriginalBugID: 4168 Bug
  Version: 8.2.1
  SubmitDate: '2000-02-14'
  LastModified: '2000-02-22'
  Severity: SER
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Macintosh
  OSVersion: Mac OS 9, Mac OS 8.5, Mac OS 8.6
  Machine: G4, G3 (blue&White)
  FixedDate: '2000-02-22'
  FixedInVersion: 8.3


  Name:
  David Caldwell

  ReproducibleScript:
  Every TK/TCL app I've run since release 8.1a has had this bug. "Widget Demos", for example, shows this error.

  ObservedBehavior:
  A Picture is worth a 1000 words...
  http://www.indigita.com/david/tk-font-bug.gif
  This shows "Widget Demos" running on my mac. G4, OS 9. I have the exact same problem on my G3 running os 8.5, 8.6, and 9.
  As you can see, many letters are displaying in the wrong font. Also, as shown in the picture, this affects the the menus to. Look at the last Q--Its in the wrong font. Weird...

  DesiredBehavior:
  I expect the letters to show up in the right font. Its almost impossible to read anything the way it is.



  This has already been fixed in the available 8.3.0 mac release. 
  -- 02/22/2000 hobbs


