# ticket

tkt_uuid: 2780147fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 76. Widget Tour
priority: 5 Medium
foundin: None
resolution: None
title: Demo - dir browser tree fails
comment:
  The directory browser tree fails on my windows system with the Tcl error:

  -------- snip ----------
  could not read "C:/~AVINSTL": no such file or directory
  could not read "C:/~AVINSTL": no such file or directory
      while executing
  "file type $f"
      (procedure "populateTree" line 8)
      invoked from within
  "populateTree $tree [$tree insert {} end -text $dir  -values [list $dir directory]]"
      (procedure "populateRoots" line 3)
      invoked from within
  "populateRoots $w.tree"
      (file "D:/Tcl/demos/Tk8.6/tree.tcl" line 81)
      invoked from within
  "source D:/Tcl/demos/Tk8.6/tree.tcl"
      ("uplevel" body line 1)
      invoked from within
  "uplevel 1 [list source [file join $tk_demoDirectory $demo.tcl]]"
      (procedure "invoke" line 12)
      invoked from within
  "invoke [.t index {@95,377}]"
      (command bound to event)

  ------------- snap -----------

  This bug can be fixed by normalizing the file paths in the proc populateTree. See attachment.


tkt_uuid: 1526437fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: no selection from disabled entry
comment:
  Selection of text from a disabled entry widget no
  longer works, starting at some version at or before 8.4.7


tkt_uuid: 3567812fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 52. [clipboard]
priority: 8
foundin: obsolete: 8.6b3
resolution: Fixed
title: [clipboard clear] segfaults
comment:
  On a --enable-aqua build on a Snow Leopard system,
  the simple command [clipboard clear] immediately segfaults.


tkt_uuid: 539309ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 79. L10N
priority: 5 Medium
foundin: None
resolution: Accepted
title: make dependence on msgcat "soft"
comment:
  Tk 8.4 adds localized widgets.  That's good.

  However, this means that Tk depends on the msgcat
  package.  In the unusual situation where msgcat
  is not installed, Tk refuses to load.  It would
  be better for Tk to load and fall back on using
  English messages.


tkt_uuid: 1118844fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: Wont Fix
title: Xft loses non-Xft fonts
comment:
  On RHEL3, I try to run the test case:

  grid [label .l -font {times 24} -text \u592a\u9177]

  On a non-Xft-enabled build, I see "tai ku" in
  the label.  On an Xft-enabled build, I see nothing.
  Moreover, on that build, I see that
  [font families] lists a different set of font families
  than 'xlsfonts' does.

  This appears to be some sort of Red Hat breakage,
  since I see the same problem with Gnome applications
  being unable to display Han characters.
  But 8.4 manages it somehow.

  Can I get some advice on how I can help
  with troubleshooting?  I'd rather not, if possible,
  have to choose between Xft and Unicode.


tkt_uuid: 220772ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 47. Win Fonts
priority: 8
foundin: None
resolution: Out of Date
title: Adapt to user requested font changes in Tk on Windows
comment:
  OriginalBugID: 599 RFE
  Version: 8.0p2
  SubmitDate: '1998-05-21'
  LastModified: '2000-04-03'
  Severity: SER
  Status: Assigned
  Submitter: hershey
  ChangedBy: ericm
  OS: All Windows
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA


  One of the oddities of using Tk on Windows can be seen by using the

  control panel to change your standard fonts.


  Do this from the Display control panel, click on the Appearance tab,

  and select an item such as ``Menu''.  You'll see that you can change

  the font.  If you do this, you'll see the running applications adapt

  to your change.  Except the ones running Tk.


  Here is the start of a patch to make Tk adapt to font changes.


  Changing the font in the control panel sends a WM_SETTINGCHANGE

  message to all programs with a parameter of SPI_SETNONCLIENTMETRICS.

  The program is supposed to fetch the new non-client metrics, and adapt

  accordingly.


  There are five fonts defined in the NONCLIENTMETRICS structure: the

  caption font, the small caption font, the menu font, the status bar

  font, and the message box font.


  This patch introduces five magic font families to match the five

  Windows non-client fonts found in the NONCLIENTMETRICS structure.

  With this patch, if you use a font in one of these magic families,

  then it will automatically adapt to changes the user makes using the

  control panel.


  For example, to make menus use the correct, user-selected, font, and

  to adapt to user requested changes correctly, you might do something

  like this:

      font create menufont -family windows-menu

      option add *Menu.Font menufont

  (This is what we are doing in our applications.)


  This patch is not complete because it does not change the default

  behaviour to use these new fonts, and because it does not update the

  documentation.  However, this functionality is fairly important for

  correct behaviour on Windows, and this patch should serve as a good

  start for implementing it.


  Ian Taylor

  ian@cygnus.com


  *** /5g/ian/tk8.0p2/generic/tkFont.c    Fri Oct 10 20:04:59 1997

  --- generic/tkFont.c    Thu Apr 16 12:41:39 1998

  *************** NewChunk(layoutPtrPtr, maxPtr, start, nu

  *** 3005,3008 ****

  --- 3005,3051 ----


        return chunkPtr;

    }

  + 

  + /*

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

  +  *

  +  * TkUpdateFonts --

  +  *

  +  *    Check all fonts to see whether they have changed.  The check

  +  *    is done by calling a function pointer passed to this routine.

  +  *

  +  *    This is used on Windows if the user changes the standard fonts

  +  *    using the control panel.

  +  *

  +  * Results:

  +  *    None.

  +  *

  +  * Side effects:

  +  *    Calls the passed in function pointer for each font, which may

  +  *    have side effects.  Calls UpdateDependantFonts for each font

  +  *    that has changed.

  +  *

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

  +  */


  + void

  + TkUpdateFonts(tkwin, changed)

  +     Tk_Window tkwin;

  +     int (*changed) _ANSI_ARGS_((TkFontAttributes *faPtr));

  + {

  +     TkFontInfo *fiPtr;

  +     Tcl_HashEntry *namedHashPtr;

  +     Tcl_HashSearch search;

  +     NamedFont *nfPtr;

  + 

  +     fiPtr = ((TkWindow *) tkwin)->mainPtr->fontInfoPtr;

  + 

  +     namedHashPtr = Tcl_FirstHashEntry(&fiPtr->namedTable, &search);

  +     while (namedHashPtr != NULL) {

  +       nfPtr = (NamedFont *) Tcl_GetHashValue(namedHashPtr);

  +       if ((*changed)(&nfPtr->fa)) {

  +           UpdateDependantFonts(fiPtr, tkwin, namedHashPtr);

  +       }

  +       namedHashPtr = Tcl_NextHashEntry(&search);

  +     }

  + }

  *** /5g/ian/tk8.0p2/generic/tkFont.h    Thu May 15 20:14:13 1997

  --- generic/tkFont.h    Thu Apr 16 12:42:38 1998

  *************** EXTERN void             TkInitFontAttributes _ANSI_

  *** 190,195 ****

  --- 190,197 ----

                              TkFontAttributes *faPtr));

    EXTERN int            TkParseXLFD _ANSI_ARGS_((CONST char *string, 

                              TkXLFDAttributes *xaPtr));

  + EXTERN void           TkUpdateFonts _ANSI_ARGS_((Tk_Window tkwin,

  +                           int (*changed) (TkFontAttributes *faPtr)));


    /*

     * Common APIs exported to tkFont.c from all platform-specific

  *** /5g/ian/tk8.0p2/win/tkWinFont.c     Thu May 15 20:15:03 1997

  --- win/tkWinFont.c     Thu Apr 16 12:47:23 1998

  *************** static TkStateMap systemMap[] = {

  *** 44,49 ****

  --- 44,63 ----

        {-1,                  NULL}

    };


  + /*

  +  * Map magic Windows font names into offsets into a NONCLIENTMETRICS

  +  * structure.

  +  */

  + 

  + static TkStateMap nonClientMap[] = {

  +     {Tk_Offset(NONCLIENTMETRICS, lfCaptionFont),      "caption"},

  +     {Tk_Offset(NONCLIENTMETRICS, lfSmCaptionFont),    "smcaption"},

  +     {Tk_Offset(NONCLIENTMETRICS, lfMenuFont),         "menu"},

  +     {Tk_Offset(NONCLIENTMETRICS, lfStatusFont),               "status"},

  +     {Tk_Offset(NONCLIENTMETRICS, lfMessageFont),      "message"},

  +     {-1,                                              NULL}

  + };

  + 

    #define ABS(x)          (((x) < 0) ? -(x) : (x))


    static TkFont *               AllocFont _ANSI_ARGS_((TkFont *tkFontPtr, 

  *************** static char *           GetProperty _ANSI_ARGS_((

  *** 53,59 ****

    static int CALLBACK   WinFontFamilyEnumProc _ANSI_ARGS_((ENUMLOGFONT *elfPtr,

                              NEWTEXTMETRIC *ntmPtr, int fontType,

                              LPARAM lParam));

  ! 


    /*

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

  --- 67,73 ----

    static int CALLBACK   WinFontFamilyEnumProc _ANSI_ARGS_((ENUMLOGFONT *elfPtr,

                              NEWTEXTMETRIC *ntmPtr, int fontType,

                              LPARAM lParam));

  ! static int            FontChanged _ANSI_ARGS_((TkFontAttributes *faPtr));


    /*

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

  *************** TkpGetFontFromAttributes(tkFontPtr, tkwi

  *** 140,194 ****

        Tk_Window tkwin;          /* For display where font will be used. */

        CONST TkFontAttributes *faPtr;  /* Set of attributes to match. */

    {

        LOGFONT lf;

        HFONT hFont;

        Window window;

        HWND hwnd;

        HDC hdc;


  !     window = Tk_WindowId(((TkWindow *) tkwin)->mainPtr->winPtr);

  !     hwnd = (window == None) ? NULL : TkWinGetHWND(window);


  !     hdc = GetDC(hwnd);

  !     lf.lfHeight               = -faPtr->pointsize;

  !     if (lf.lfHeight < 0) {

  !       lf.lfHeight = MulDiv(lf.lfHeight, 

  !               254 * WidthOfScreen(Tk_Screen(tkwin)),

  !               720 * WidthMMOfScreen(Tk_Screen(tkwin)));

  !     }

  !     lf.lfWidth                = 0;

  !     lf.lfEscapement   = 0;

  !     lf.lfOrientation  = 0;

  !     lf.lfWeight               = (faPtr->weight == TK_FW_NORMAL) ? FW_NORMAL : FW_BOLD;

  !     lf.lfItalic               = faPtr->slant;

  !     lf.lfUnderline    = faPtr->underline;

  !     lf.lfStrikeOut    = faPtr->overstrike;

  !     lf.lfCharSet      = DEFAULT_CHARSET;

  !     lf.lfOutPrecision = OUT_DEFAULT_PRECIS;

  !     lf.lfClipPrecision        = CLIP_DEFAULT_PRECIS;

  !     lf.lfQuality      = DEFAULT_QUALITY;

  !     lf.lfPitchAndFamily = DEFAULT_PITCH | FF_DONTCARE;

  !     if (faPtr->family == NULL) {

  !       lf.lfFaceName[0] = '\0';

        } else {

  !       lstrcpyn(lf.lfFaceName, faPtr->family, sizeof(lf.lfFaceName));

  !     }

  !     ReleaseDC(hwnd, hdc);


  !     /*

  !      * Replace the standard X and Mac family names with the names that

  !      * 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");

        }


        hFont = CreateFontIndirect(&lf);

  --- 154,227 ----

        Tk_Window tkwin;          /* For display where font will be used. */

        CONST TkFontAttributes *faPtr;  /* Set of attributes to match. */

    {

  +     int offset;

        LOGFONT lf;

        HFONT hFont;

        Window window;

        HWND hwnd;

        HDC hdc;


  !     /* 

  !      * Magic handling for fonts in the windows-* family.

  !      */

  !     if (faPtr->family != NULL

  !           && strncmp(faPtr->family, "windows-", 8) == 0

  !           && (offset = TkFindStateNum(NULL, NULL, nonClientMap,

  !                       faPtr->family + 8)) >= 0) {

  !       NONCLIENTMETRICS ncm;

  ! 

  !       ncm.cbSize = sizeof(ncm);

  !       if (! SystemParametersInfo(SPI_GETNONCLIENTMETRICS, sizeof(ncm),

  !                       (void *) &ncm, 0)) {

  !           panic("TkpGetFontFromAttributes: SystemParametersInfo failed");

  !       }


  !       lf = *(LOGFONT *)((char *) &ncm + offset);

        } else {

  !       window = Tk_WindowId(((TkWindow *) tkwin)->mainPtr->winPtr);

  !       hwnd = (window == None) ? NULL : TkWinGetHWND(window);


  !       hdc = GetDC(hwnd);

  !       lf.lfHeight             = -faPtr->pointsize;

  !       if (lf.lfHeight < 0) {

  !           lf.lfHeight = MulDiv(lf.lfHeight, 

  !                   254 * WidthOfScreen(Tk_Screen(tkwin)),

  !                   720 * WidthMMOfScreen(Tk_Screen(tkwin)));

  !       }

  !       lf.lfWidth              = 0;

  !       lf.lfEscapement = 0;

  !       lf.lfOrientation        = 0;

  !       lf.lfWeight             = (faPtr->weight == TK_FW_NORMAL) ? FW_NORMAL : FW_BOLD;

  !       lf.lfItalic             = faPtr->slant;

  !       lf.lfUnderline  = faPtr->underline;

  !       lf.lfStrikeOut  = faPtr->overstrike;

  !       lf.lfCharSet    = DEFAULT_CHARSET;

  !       lf.lfOutPrecision       = OUT_DEFAULT_PRECIS;

  !       lf.lfClipPrecision      = CLIP_DEFAULT_PRECIS;

  !       lf.lfQuality    = DEFAULT_QUALITY;

  !       lf.lfPitchAndFamily = DEFAULT_PITCH | FF_DONTCARE;

  !       if (faPtr->family == NULL) {

  !           lf.lfFaceName[0] = '\0';

  !       } else {

  !           lstrcpyn(lf.lfFaceName, faPtr->family, sizeof(lf.lfFaceName));

  !       }

  !       ReleaseDC(hwnd, hdc);


  !       /*

  !        * Replace the standard X and Mac family names with the names that

  !        * 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");

  !       }

        }


        hFont = CreateFontIndirect(&lf);

  *************** AllocFont(tkFontPtr, tkwin, hFont)

  *** 640,643 ****

  --- 673,709 ----


        return (TkFont *) fontPtr;

    }

  + 

  + /*

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

  +  *

  +  * TkWinNCMetricsChanged, FontChanged --

  +  *

  +  *    Called when the non client metrics change to update all the

  +  *    information for the magic Windows fonts.

  +  *

  +  * Results:

  +  *    None.

  +  *

  +  * Side effects:

  +  *    Updates font information in generic TkFont code.

  +  *

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

  +  */

  + 

  + void

  + TkWinNCMetricsChanged(tkwin)

  +     Tk_Window tkwin;

  + {

  +     TkUpdateFonts(tkwin, FontChanged);

  + }


  + static int

  + FontChanged(faPtr)

  +     TkFontAttributes *faPtr;

  + {

  +     return (faPtr->family != NULL

  +           && strncmp(faPtr->family, "windows-", 8) == 0

  +           && TkFindStateNum(NULL, NULL, nonClientMap,

  +                             faPtr->family + 8) >= 0);

  + }

  *** /5g/ian/tk8.0p2/win/tkWinInt.h      Thu Oct  9 13:40:17 1997

  --- win/tkWinInt.h      Thu Apr 16 12:47:44 1998

  *************** extern int              TkWinHandleMenuEvent _ANSI_A

  *** 165,170 ****

  --- 165,171 ----

                              UINT *pMessage, WPARAM *pwParam, LPARAM *plParam,

                              LRESULT *plResult));

    extern int            TkWinIndexOfColor _ANSI_ARGS_((XColor *colorPtr));

  + extern void           TkWinNCMetricsChanged _ANSI_ARGS_((Tk_Window tkwin));

    extern void           TkWinPointerDeadWindow _ANSI_ARGS_((TkWindow *winPtr));

    extern void           TkWinPointerEvent _ANSI_ARGS_((HWND hwnd, int x,

                              int y));

  *** /5g/ian/tk8.0p2/win/tkWinWm.c       Fri Oct 31 12:57:07 1997

  --- win/tkWinWm.c       Thu Apr 16 12:47:57 1998

  *************** WmProc(hwnd, message, wParam, lParam)

  *** 3959,3964 ****

  --- 3959,3973 ----

              result = 0;

              goto done;


  +       case WM_SETTINGCHANGE:

  +           if (wParam == SPI_SETNONCLIENTMETRICS) {

  +               winPtr = GetTopLevel(hwnd);

  +               if (winPtr != NULL) {

  +                   TkWinNCMetricsChanged((Tk_Window) winPtr);

  +               }

  +           }

  +           break;

  + 

          default:

              break;

        }




  Good idea, but we should use something like "systemMenuFont" or similar, to emphasize that it is a system font.

  - eric

  -- 04/03/2000 ericm


tkt_uuid: 3588824fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
severity: Minor
foundin: current: 8.6.0
resolution: Fixed
title: Text widget: bug in image index handling
comment:
  The [$text index $image] subcommand fails with images which contains "+", "-"  or spaces in their names.

  Sample script:

  package require Tk
  text .t
  .t image create 1.0 -image [image create photo ::foo]
  .t image create 1.1 -image [image create photo ::foo-1]
  puts [.t image names]
  foreach img [.t image names] {
      puts [.t index $img]
  }

  Output:

  ::foo ::foo-1
  1.0
  bad text index "::foo-1"

  The source code in generic/tkTextIndex.c checkes first for a mark name
  alone before trying to parse the provided input as "base+modifier", thus
  allowing mark names with spaces or "+- " chars.

  The attached patch solves the issue simply performing the same check
  for an image name after the one for marks.


tkt_uuid: 671122ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: None
resolution: Fixed
title: wish crashed with -visual truecolor when packing a panedwin
comment:
  wish crashes when a panedwindow is created.

  The script is as follows:

  % wish8.4 -visual truecolor

  toplevel .t
  panedwindow .t.p
  frame .t.p.1 -bg green
  frame .t.p.2 -bg blue
  pack .t.p.1 -expand yes -fill both
  pack .t.p.2 -expand yes -fill both
  .t.p add .t.p.1
  .t.p. add .t.p.2
  pack .t.p -expand yes -fill both
  % X Error of failed request:  BadMatch (invalid parameter attributes)
    Major opcode of failed request:  70 (X_PolyFillRectangle)
    Serial number of failed request:  138
    Current serial number in output stream:  139

  Note: wish does not crash when invoked without -visual truecolor

  This occured on a Silicon Graphics SGI O2 (standard display & flat screen)
  R5000, 256 Mb 

  I'd consider this a serious bug.


tkt_uuid: 636358ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 6
foundin: obsolete: 8.4.2
resolution: Out of Date
title: File selector unstable
comment:
  The file selector (when called from my client app) often leads to a 
  complete crash (using Tcl/Tk Aqua Runtime Jaguar), when 
  browsing a directory. Usually happens, when some directory is 
  clicked. (Might be coincidence: crash occurred quite often when 
  working on a network volume. Very often happens when scrolling 
  through a folder with mouse wheel.) 

  Error occurrs with RSTTool 3.32 (www.wagsoft.com)


tkt_uuid: 220617ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: obsolete: 8.2.2
resolution: Fixed
title: <<ListboxSelect>> not documented
comment:
  OriginalBugID: 3500 Bug
  Version: 8.2.2
  SubmitDate: '1999-11-08'
  LastModified: '1999-12-16'
  Severity: LOW
  Status: Released
  Submitter: hobbs
  ChangedBy: hobbs
  OS: All
  FixedDate: '1999-12-16'
  FixedInVersion: 8.3b1


  Should also make examples of using it.

  This is in 8.3b1. 
  -- 12/16/1999 hobbs


tkt_uuid: 701927ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.4.2
resolution: None
title: extremely long, fat lines not displayed
comment:
  Tk user reports:

  > extremely long
  > lines still don't render if their width is bigger
  than 1.  For example:
  > 
  >    canvas .c -width 100 -height 100 -bg white
  >    pack .c
  >    set xbig [expr {pow(2,31)-3}]
  >    .c create line 0 30 $xbig 30 -fill red -width 1
  >    .c create line 0 50 $xbig 50 -fill blue -width 2
  > 
  > The second line isn't visible.

  Problem exists in both 8.4.2 and 8.4.1 on Win2K,
  and in 8.3.4 on Linux/Alpha.

  This is not a duplicate of 663981 or 630171.

  Might be related to Tk Bug 559792 ?


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

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


tkt_uuid: 741179ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: text-15.* fails to clear font
comment:
  $ make test TESTFLAGS="-file text.test -match text-15.*"
  TCL_LIBRARY=/local/src/tcl/library; export TCL_LIBRARY; \
  TK_LIBRARY=/local/src/tk/library; export TK_LIBRARY; \
  ./tktest /local/src/tk/unix/../tests/all.tcl -geometry
  +0+0 \
  -file text.test -match text-15.* 
  Tests running in interp:  /local/src/tk/solaris/tktest
  Tests located in:  /local/src/tk/tests
  Tests running in:  /local/src/tk/solaris
  Temporary files stored in /local/src/tk/solaris
  Test files sourced into current interpreter
  Running tests that match:  text-15.*
  Skipping test files that match:  l.*.test
  Only running test files that match:  text.test
  Tests began at Wed May 21 11:11:07 AM EDT 2003
  text.test

  Tests ended at Wed May 21 11:11:08 AM EDT 2003
  all.tcl:        Total   358     Passed  2       Skipped
  356     Failed  0
  Sourced 2 Test Files.
  Font Courier -12 still in cache.


  Note the final line.


tkt_uuid: 942320ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 46. Unix Fonts
priority: 5 Medium
foundin: obsolete: 8.5a2
resolution: Fixed
title: Tk, Xft, text and long lines
comment:
  Andreas Leitgeb reports on c.l.t:

  I've got some application, that uses Tk's text-widget and
  inserts lines which are sometimes very long (10000
  chars or more)
  with wrapping turned off (-wrap none).
  [...]
  Recently I tried  Xft, and noticed that these
  long lines wrap around at 65536 pixels (about 9362
  chars with my
  default font). The next characters overwrite the start
  of the line.
  This does not happen with xft disabled.


tkt_uuid: 911951ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.5a1
resolution: None
title: Menu geometry info wrong if cascaded
comment:
  If you post a menu directly with the post widget
  command, or associate it with a menubutton and click on
  that to post it, you can get info about its position
  using the wm or winfo commands. However if you display
  it by clicking on a cascade entry in another menu, this
  information is wrong. The geometry comes up as 0x0+1+1
  if it is displayed for the first time, or whatever it
  was when it was last invoked directly or from a menubutton.

  Tested on TclTk 8.4.2 with red hat linux 7.3
  and 8.4.3, 8.4.6, and 8.5a1 with red hat linux 9


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


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

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


tkt_uuid: 1989808fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
resolution: Accepted
title: extra ttk::notebook bindings
comment:
  It seems common, at least on Windows, to have PageUp and PageDown ky bindings for the notebook to cycle tabs. Firefox has it. Moreover, it binds not only to subwidgets of the notebook, but to any widget in the toplevel. Below is some code, mostly picked from library/ttk/notebook.tcl and modified.


  # Provides some extra bindings and workarounds for ttk::notebooks.
  # Code from ttk.

  namespace eval tileutils::nb {
      variable TLNotebooks
  }

  proc tileutils::nb::Traversal {nb} {
      variable TLNotebooks

      ttk::notebook::enableTraversal $nb

      set top [winfo toplevel $nb]
      if {![info exists TLNotebooks($top)]} {
  bind $top <Control-Next>  {+tileutils::nb::TLCycleTab %W  1}
  bind $top <Control-Prior> {+tileutils::nb::TLCycleTab %W -1}
  bind $top <Destroy>       {+tileutils::nb::TLCleanup %W}
      }
      bind $nb <Destroy> {+tileutils::nb::Cleanup %W}
      lappend TLNotebooks($top) $nb
  }

  # ActivateTab $nb $tab --
  #Select the specified tab and set focus.
  #
  # If $tab was already the current tab, set the focus to the
  #notebook widget.  Otherwise, set the focus to the first
  #traversable widget in the pane.  The behavior is that the
  #notebook takes focus when the user selects the same tab
  #a second time.  This mirrors Windows tab behavior.
  #
  proc tileutils::nb::ActivateTab {w tab} {
      if {[$w index $tab] eq [$w index current]} {
  focus $w
      } else {
      $w select $tab
  update ;# needed so focus logic sees correct mapped/unmapped states
  if {[set f [ttk::focusFirst [$w select]]] ne ""} {
      tk::TabToWindow $f
  }
      }
  }

  # CycleTab --
  #Select the next/previous tab in the list.
  #
  proc tileutils::nb::CycleTab {w dir} {
      if {[$w index end] != 0} {
  set current [$w index current]
  set select [expr {($current + $dir) % [$w index end]}]
  while {[$w tab $select -state] != "normal" && ($select != $current)} {
      set select [expr {($select + $dir) % [$w index end]}]
  }
  if {$select != $current} {
      ActivateTab $w $select
  }
      }
  }

  # tileutils::nb::ClosestNotebook --
  #       Finds notebook in toplevel that in some sense is closest to w.
  #
  proc tileutils::nb::ClosestNotebook {w} {    
      variable TLNotebooks
      
      set top [winfo toplevel $w]
      if {![info exists TLNotebooks($top)]} { return }
      if {[llength $TLNotebooks($top)] == 1} {
  return [lindex $TLNotebooks($top) 0] 
      }
      
      # Enclosing notebook.
      foreach nb $TLNotebooks($top) {
  if {[regexp ^$nb $w]} {
      return $nb
  }
      }
      
      # Find largest common part.
      set win $w
      while {($win ne $top) && ($win ne "")} {
  foreach nb $TLNotebooks($top) {
      if {[regexp ^$nb $win]} {
  return $nb
      }
  }
  set win [winfo parent $win]
      }
      return
  }

  # TLCycleTab --
  #toplevel binding procedure for Control-Tab / Shift-Control-Tab
  #Select the next/previous tab in the nearest ancestor notebook. 
  #
  proc tileutils::nb::TLCycleTab {w dir} {
      set nb [ClosestNotebook $w]
      if {$nb ne ""} {
  CycleTab $nb $dir
  return -code break
      }
  }

  # TLCleanup -- <Destroy> binding for traversal-enabled toplevels
  #
  proc tileutils::nb::TLCleanup {w} {
      variable TLNotebooks
      if {$w eq [winfo toplevel $w]} {
  unset -nocomplain -please TLNotebooks($w)
      }
  }

  # Cleanup -- <Destroy> binding for notebooks
  #
  proc tileutils::nb::Cleanup {nb} {
      variable TLNotebooks
      set top [winfo toplevel $nb]
      if {[info exists TLNotebooks($top)]} {
  set index [lsearch -exact $TLNotebooks($top) $nb]
          set TLNotebooks($top) [lreplace $TLNotebooks($top) $index $index]
      }
  }


tkt_uuid: 3602534fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 4
foundin: None
resolution: Fixed
title: XScreensaver test pollutes XLIBSW variable
comment:
  The XLIBSW variable is used for a few tests and the XScreensave tests might alter it.
  Easiest fix is to do the XScreensaver tests last.
  Ok?


tkt_uuid: 220427ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: Errors using tkfbox dialogs on different windows
comment:
  OriginalBugID: 1156 Bug
  Version: 8.0p2
  SubmitDate: '1999-02-02'
  LastModified: '1999-11-30'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: SunOS 5.5.1
  Machine: Other
  FixedDate: '1999-11-30'
  FixedInVersion: 8.2


  Name:
  Nancy Aten

  Extensions:
  (Symptom occurs in vanilla wish). Our product includes blt tktable img.

  CustomShell:
  (Symptom occurs in vanilla wish). In our product version, yes, I have applied plus-patch and redefined things like puts.

  ReproducibleScript:
  wish
  toplevel .test1
  toplevel .test2
  tk_getSaveFile -parent .test1 -filetypes {{all *}}
  tk_getSaveFile -parent .test2 
  destroy .test2
  tk_getSaveFile -parent .test1 -filetypes {{all *}}
  Error: invalid command name ".test2.__tk_filedialog.f3.menu.m"

  ObservedBehavior:
  Tk is unable to raise the save (or open) file dialog and gives an error message.
  This problem did not exist in 8.0 earlier versions, but in 8.0p2, tkfbox uses parent-window-specific __tk_filedialog data, rather than always using .__tk_filedialog. The problem I'm seeing is at line 663 of tkfbox.tcl - in tkFDialog, step (5. Initialize the file types menu), $data(typeMenu) is still pointing at the last-used-dialog, which in the example above no longer exists because its parent was destroyed.

  DesiredBehavior:
  Re-accessing an existing file dialog for that parent window needs to reset the relevant data fields to its own context.
  The dialog should open normally in the above script.



  I cannot repeat this in 8.2, so I'll assume it was fixed
  along the way. 
  -- 11/30/1999 hobbs


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

  Eg:

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

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


tkt_uuid: 222677ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: None
title: toplevel with '-use 0x...' doesn't receive <Destroy> e
comment:
  This is on Windows 2000 pro, service pack 1.

  keywords: embedding, -use, -container.

  Start up two copies of wish.  In the first, type:

  % toplevel .t -container 1
  .t
  % winfo id .t
  0x290526
  % bind .t <Destroy> {puts "destroyed %W"}
  % 

  In the second, type:

  % toplevel .s -use 0x290526
  .s
  % bind .s <Destroy> {puts "destroyed %W"}
  % 

  Now, '.s' is embedded inside '.t', which is great!  (very cool functionality!).  However, if I now destroy .t (by, say, clicking on the close-box), a message:

  destroyed .t

  appears in the console of the first wish, but no corresponding 'destroyed .s' message every appears (and in fact '.s' still exists, but is just not shown anywhere):

  % winfo children .
  .s
  % wm geometry .s
  200x200+0+0
  % winfo ismapped .s
  1
  % .s cget -use
  0x290526
  % wm state .s
  withdrawn
  % wm deiconify .s
  can't deiconify .s: it is an embedded window

  Is this the desired behaviour?  Whether it is or not, does anyone know of any workarounds?  How can the interpreter that owns '.s' find out that .s has ceased to be a useful window...?

  cheers,

  Vince.


tkt_uuid: 1386955fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Tiny enhancement to the documentation
comment:
  Hi there,
  while the 'console' command is documented along all
  other  Tk commands, it is special in that it is not
  available via a 'package require Tk'. Maybe this should
  be mentioned?
  I suggest the following: To the first paragraph of the
  section 'Description' add:
     >>>
  Note: This command is only available from within
  "wish", not via a [package require Tk] from tclsh.
     <<<

  Thanks and best regards
  Helmut Giese


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

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

  #ifndef WS_EX_TOOLWINDOW
  #define WS_EX_TOOLWINDOW0x00000080L 
  #endif

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


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

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

  I'd very interested in comments.

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


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

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

  This allows the list to be dynamically created.



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

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


tkt_uuid: 3192483fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: Invalid
title: undo/redo not properly working
comment:
  Try the following script:

  -------------------------------------------------------------------------------------
  set bold [list [font configure TkTextFont -family] [font configure TkTextFont -size] bold]
  pack [text .t -font TkTextFont -undo yes]
  .t tag configure bold -font $bold
  .t insert insert "the last word is "
  .t insert insert "bold" bold
  .t insert insert "."
  -------------------------------------------------------------------------------------

  Now do the following:
  1. Select the word "bold"
  2. Delete this word (press DEL)
  3. Undo the change (press Ctrl-z)

  After the undo the word "bold" has the wrong font. The undo/redo mechanism should regard the tags, otherwise the result is wrong. E.g in my application I'm using special fonts with the use of tags. If I enter a special symbol "\u0001" of this font (with the appropriate tag), after delete & undo this symbol will be shown with the wrong font, that means it is the wrong text (garbage in this case).


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




  04/28/1999 14:00 - kenj - Former Tk function now incorporated in Tcl. Tcl API documented in the Tcl man pages. Tk usage deprecated.


tkt_uuid: 220007ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 1 Zero
foundin: None
resolution: Duplicate
title: Printing tcl source from a wish window on NT
comment:
  OriginalBugID: 2430 RFE
  Version: 8.2b1
  SubmitDate: '1999-07-21'
  LastModified: '1999-12-22'
  Severity: LOW
  Status: Closed
  Submitter: jenn
  ChangedBy: hobbs
  RelatedBugIDs: 1954
  OS: Windows NT
  ClosedDate: '1999-12-22'


  I am developing now database applications with tcl and I should have the
  possibility to print from wish, like in other programs (MS-Access) with full
  printer support.  At the moment, I print the data in a file and later I type the file to the printer.  I think this method is not very elegant !!!


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

  Prolematic code:

  win/tkWinButton.c, near line 204

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

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

  Stack trace:

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


tkt_uuid: 542199ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 07. [entry]
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: None
title: entry widget: Dclick on character selection problem
comment:
  The bug was originally part of 220943. A number
  of problems were created by an earlier change.
  The problem described as (2) was not caused by the
  modification and so it has been extracted into
  this bug report. Test cases and the proposed
  patch have been added here.

  It is included here.

  (2) Double-click on the "c" in the first line, near its
  RIGHT edge. The "c" becomes selected, as it should.
  Now, double-click on the "c" near its LEFT edge,
  keeping the button down after the second click. The
  space to the left of the "c" is selected, not the "c"
  itself. Now, move the mouse by ONE PIXEL in any
  direction. The "ab" becomes selected as well.

  ...

  The behavior described in (1) and (2) is obviously
  incorrect. (In the case of clicking on the "c" near its
  left edge, you might argue that you are effectively
  clicking on the gap between the space and the "c" and
  that therefore it is not necessarily incorrect for the
  space to be the thing selected; but it certainly is
  counterintuitive, since one expects the letter clicked
  on to be part of the selected text.)


tkt_uuid: 919066ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 41. Photo Images
priority: 8
foundin: obsolete: 8.4.5
resolution: Remind
title: Slow processing irregular transparencies
comment:
  If you have a photo image with irregular transparent
  patches dotted around it it takes an atrociously long
  time to copy. It seems to be exponentially related to
  image size. For instance, here it takes about 2.5
  minutes of CPU time on my Athlon XP1600 to create this
  fairly compact 750x500 image by tiling a small but
  holey initial image (attached)...

  % info patchlevel
  8.4.2
  % image create photo p1 -file flip_v.gif
  p1
  % image create photo p2
  p2
  % p2 copy p1 -to 0 0 750 500
  < 150 second pause occurs here>
  %


tkt_uuid: 700993ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 50. [pack]
priority: 4
foundin: None
resolution: Out of Date
title: Pack may fail to show a button in aqua Tk 8.4.1
comment:
  The following scrip demonstrates a problem first reported by "Larry" on the MacPython mailing list. He said the bug did not appear on Windows but did appear on MacOS X.

  The problem is that the box brought up when you press the Demo button does not show the "OK" button until you click in the resize box. (Again, only on MacOS X, and at least in my case, only when using aqua Tk).

  The script shown is a simple a version as I could make. I also tried some variants which did NOT reliably show the problem:
  - Simply painting the dialog box (instead of pressing a button to bring it up) works fine (the OK button is shown).
  - Using after to paint the dialog box 50 ms later (instead of making the user push a button) is a weird borderline case; sometimes the button is not shown at first, but as soon I click on the dialog to bring it to the front then the OK button appears.

  In any case, this script reproduces the bug completely reliably on MacOS X 10.2.3 (at least) and in aqua Tk 8.4.1:


  button .demo -text "Demo" -command {
  toplevel .dlg
  label .dlg.txt -text "No OK button?\nClick in resize (lower right) to see it."
  pack .dlg.txt
  button .dlg.but -text "OK" -command { destroy .msgdlg }
  pack .dlg.but
  }
  pack .demo


tkt_uuid: 219947ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 1 Zero
foundin: obsolete: 8.1b2
resolution: Duplicate
title: wish hangs on Windows after spawning itself via fileevent
comment:
  OriginalBugID: 1594 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-22'
  LastModified: '1999-03-26'
  Severity: CRIT
  Status: Closed
  Submitter: hershey
  ChangedBy: surles
  RelatedBugIDs: 1495
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA
  ClosedDate: '1999-03-26'


  If you source the following script in the wish81b2 on windows, it
  hangs after printing the exe name.  Note that two wish81.exe processes
  are running when the app is hung, and if you kill the second one, then
  the first one continues.  This code was taken directly from the
  defs.tcl test suite file.

  set tcltest [info nameofexecutable]
  puts $tcltest
  update
  puts "goodbye"
  flush stdout

  catch {
      file delete -force tmp
      set f [open tmp w]
      puts $f {
  exit
      }
      close $f
      set f [open "|[list $tcltest tmp]" r]
      close $f
  }
  catch {file delete -force tmp}


  Duplicate bug ID 1495.


tkt_uuid: 1476443fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.13
resolution: Fixed
title: Some toplevels are drawn in the wrong place
comment:
  My application (a control system) has many toplevels.
  It remembers their positions and restores those next time.

  Aqua Tcl/Tk 8.4.13 has introduced a bug in this at
  startup: a few of my toplevels are consistently drawn
  in the wrong location.

  I have not been able to trace what is different about
  the few toplevels that are place incorrectly and the
  others, but it is completely reproducible (it is always
  the same two, and they are always drawn in the same
  incorrect location).

  I create the toplevels as follows:
  - create a toplevel
  - withdraw it
  - set its title
  - add its widgets
  - set its geometry (position only if not resizable)
  - deiconify it (make it visible)

  For the toplevels that are in the wrong place:
  - If I read the geometry immediately after the
  deiconfy, the read position is what I asked for (not
  where it actually is displayed).
  - If I read the geometry after update idletasks after
  deiconify, the reported position is where it is
  displayed (not where I asked it to be).

  A workaround: if I call "update idletasks" before
  setting geometry then the problem goes away.

  Configuration:
  - MacOS X 10.3.9 (PPC)
  - Aqua Tcl/Tk 8.4.13, in particular
  ActiveTcl8.4.13.0.261555-macosx-powerpc-threaded.dmg
  (the 8.4.13 release)

  I did NOT see the problem using the same OS and using
  ActiveTcl8.4.13.0.260592-macosx-powerpc-threaded.dmg (a
  prerelease). Nor have I seen it with any older version
  of Aqua Tcl/Tk (and I've used almost all of them).


tkt_uuid: 1376154fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: obsolete: 8.5a4
resolution: Out of Date
title: tk::IconList_Curselection instead of tk::IconLisCurSelection
comment:
  IconList_Curselection seems to be renamed to
  tk::IconList_CurSelection (capital S in Selection)

  but in choosedir.tcl, tclIndex and unsupported the old
  syntax already exists. tk_chooseDir is broken. 


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

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

  The error message is:
  unknown option "180"

  When you leave out the braces, all is well.


tkt_uuid: 2492179fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 9 Immediate
foundin: obsolete: 8.6b1
resolution: Fixed
title: config.test failures - DoObjConfig
comment:
  Don't recall seeing these before:

  config.test


  ==== config-4.111 DoObjConfig - custom FAILED
  ==== Contents of test case:

      testobjconfig alltypes .foo -custom test

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0
  ---- errorInfo: unknown color name "test"
      (processing "-custom" option)
      invoked from within
  "testobjconfig alltypes .foo -custom test"
      ("uplevel" body line 2)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== config-4.111 FAILED



  ==== config-4.112 DoObjConfig - custom FAILED
  ==== Contents of test case:

      testobjconfig alltypes .foo -custom test
      .foo cget -custom

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0
  ---- errorInfo: unknown color name "test"
      (processing "-custom" option)
      invoked from within
  "testobjconfig alltypes .foo -custom test"
      ("uplevel" body line 2)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== config-4.112 FAILED



  ==== config-7.13 Tk_SetOptions - error in DoObjConfig with custom option FAILED
  ==== Contents of test case:

      .a configure -custom bad

  ---- Result was:
  unknown color name "bad"
  ---- Result should have been (exact matching):
  expected good value, got "BAD"
  ==== config-7.13 FAILED



  ==== config-7.14 Tk_SetOptions - error in DoObjConfig with custom option FAILED
  ==== Contents of test case:

      catch {.a configure -custom bad}
      return $errorInfo

  ---- Result was:
  unknown color name "bad"
      (processing "-custom" option)
      invoked from within
  ".a configure -custom bad"
  ---- Result should have been (exact matching):
  expected good value, got "BAD"
      (processing "-custom" option)
      invoked from within
  ".a configure -custom bad"
  ==== config-7.14 FAILED


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

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


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

  basically it just makes some changes to tkMacOSXDraw.c

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

  unfortunately, it doesn't cover pixmaps (yet)

  ...or get rid of copybits (yet)

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

  tested with 10.2.6-10.2.8

  ...known bugs:  

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


tkt_uuid: 220807ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 74. Application Embedding
priority: 7 High
foundin: obsolete: 8.1b3
resolution: None
title: Docs missing for Tk_MainEx API
comment:
  OriginalBugID: 1875 Bug
  Version: 8.1b3
  SubmitDate: '1999-04-16'
  LastModified: '1999-04-22'
  Severity: MED
  Status: Assigned
  Submitter: surles
  ChangedBy: hershey
  OS: All
  OSVersion: NA
  Machine: NA
  FixedInVersion: NA


tkt_uuid: 2874226fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 82. X11 Emulation
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: None
title: polygon don't honor -joinstyle on Windows
comment:
  Under Windows, the following code:

  pack [canvas .c]
  set id [.c create polygon {20.0 20.0 50.0 50.0 30.0 80.0 20.0 50.0 20.0 30.0}]
  .c itemconfigure $id -fill red -outline black -width 10 -joinstyle miter

  shows a polygon with a round close point, while the -joinstyle is miter.

  See the attached image: left is Unix, right is Windows.

  Documentation of XDrawLines() says that it honors joinstyle if first and last point are identical.
  The XDrawLines() implementation in tkWinDraw.c should do the same thing.

  Or is it a limitation of GDI Polygon function?


tkt_uuid: 220591ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: possible mispackaging
comment:
  OriginalBugID: 2686 Bug
  Version: 8.2
  SubmitDate: '1999-09-01'
  LastModified: '1999-09-01'
  Severity: LOW
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  Machine: X86
  FixedDate: '1999-09-01'


  Name:
  Hume Smith

  ReproducibleScript:
  puts $tcl_patchLevel,$tk_patchLevel

  ObservedBehavior:
  this printed
      8.2.0,8.2b3
      on my freshly-DLed-and-installed Winduhs 8.2 binary... the next oldest
      version ever to touch this machine is 8.0.something, so it's probably
      not some sort of collision with a previous version.

  DesiredBehavior:
  i expected to see
      8.2.0,8.2.0



  This was a problem in labelling only, and is now fixed.  The
  actual libraries are both 8.2.0. 
  -- 09/01/1999 hobbs


tkt_uuid: 220267ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.3b1
resolution: Invalid
title: Elided text not mentioned in text man page
comment:
  OriginalBugID: 3968 Bug
  Version: 8.3b1
  SubmitDate: '2000-01-03'
  LastModified: '2000-01-03'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: AIX
  OSVersion: 4.3.3
  Machine: RS/6000 43P Model 150
  ClosedDate: '2000-01-03'


  Name:
  Dave Marquardt

  ReproducibleScript:
  Build and install Tk 8.3b1.  Run "man text."  Notice that elided text isn't mentioned anywhere.

  ObservedBehavior:
  The elided text patch is supposed to be part of Tk 8.3b1, and apparently is, since TkMan works with wish8.3 without patching the Tk source code.  But this feature is not mentioned in the text man page.

  DesiredBehavior:
  Describe elided text in "text" man page.



  It is mentioned under TAGS as -state hidden, which is the option
  to attain it.  It may change in 8.3b2 to -elide TCL_BOOLEAN instead. 
  -- 01/03/2000 hobbs


tkt_uuid: 3406785fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.6b2
resolution: None
title: Incorrect coords rounding --- pixel jump in drawing items
comment:
  Look at result of this script:
  -----
  canvas .c -bg white
  grid .c
  set x1 20
  set x2 22
  set y2 105
  for {set f 0} {$f<50} {incr f} {
      set y1 [expr {$y2-0.05*$f}]
      .c create rectangle $x1 $y1 $x2 $y2 -fill black
      incr x1 2
      incr x2 2
      }
  -----

  On Windows XP I see that at left side of figure bottom margin is one pixel lower than at right side. But it shouldn't happen as y2 is the same
  (105) for all rectangles. Also, DKF confirmed the bug on OSX, and with both 8.5 and 8.6. 


tkt_uuid: 2907758fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 7 High
foundin: obsolete: 8.5.7
resolution: Fixed
title: crash with CFStringGetCString
comment:
  Hi, some aMSN users started reporting that aMSN crashes for them on their mac, and we don't know what's causing it and can't reproduce.. It seems to be coming from Tk_CreateMainWindow, so i don't think it has anything to do with amsn's source code or extensions. Here are a few stack traces as reported by the users..
  http://www.amsn-project.net/forums/viewtopic.php?t=7392
  http://www.amsn-project.net/forums/viewtopic.php?t=7429
  If you look at the traces, it seems to be happening on 10.5.8 and 10.5.4 with both tcl/tk 8.5.3 (amsn 0.97.2 and 0.98) and 8.5.7 (amsn 0.98.1).

  For completeness sake, here's a paste of one of the crash reports :
   
   
  Exception Type: EXC_BAD_ACCESS (SIGBUS) 
  Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000 
  Crashed Thread: 0

  Thread 0 Crashed: 
  0 com.apple.CoreFoundation 0x966ac173 CFStringGetCString + 307 
  1 com.tcltk.tklibrary 0x0b0b8fcf Tk_DrawChars + 654 
  2 com.tcltk.tklibrary 0x0b0b945d Tk_DrawChars + 1820 
  3 ...ple.ApplicationServices.ATS 0x94617ef4 ATSFontFamilyApplyFunction + 138 
  4 com.tcltk.tklibrary 0x0b0b91a1 Tk_DrawChars + 1120 
  5 com.tcltk.tklibrary 0x0b02d907 TkCreateMainWindow + 171 
  6 com.tcltk.tklibrary 0x0b0366a8 Tk_UndefineCursor + 35419 
  7 com.tcltk.tklibrary 0x0b036ad7 TkCreateFrame + 140 
  8 com.tcltk.tklibrary 0x0b02cdc5 Tk_GetNumMainWindows + 2059 
  9 com.tcltk.wish.amsn 0x000111ee 0x1000 + 66030 
  10 com.tcltk.tklibrary 0x0b01ef98 Tk_MainEx + 1563 
  11 com.tcltk.wish.amsn 0x000111cb 0x1000 + 65995 
  12 com.tcltk.wish.amsn 0x00011186 0x1000 + 65926 
  13 com.tcltk.wish.amsn 0x000110ad 0x1000 + 65709


  I hope this can be fixed soon. thanks.


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

  Here is a patch to correct it:

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


tkt_uuid: 1118589fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.4.5.1
resolution: Works For Me
title: Menu focus issue
comment:
  Issues with focus on menu, or inconsistancy with
  operation of other widgets.  Problem seen under
  MandrakeLinux 10.1 official.  See following script:

  button .b
  menu .m
  .m add command -label test
  .m add command -label test2
  after 5000 {pack .b; focus .b; .m post 0 0; .m activate
  1; tk_menuSetFocus .m}

  Expected focus to be on menu, but ends up on button. 
  Tests with other widgets like entry show that focus
  does indeed end up on entry.

  button .b
  entry .e
  after 5000 {pack .b; pack .e; focus .b; focus .e}

  This is causing some grief on systems that don't have a
  mouse.


tkt_uuid: 2949069fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 01. Bindings
priority: 5 Medium
foundin: None
resolution: None
title: ttk::combobox - correct (and full) operation on Windows.
comment:
  This is add-on code that I have made to make ttk::combobox function properly on Windows. This includes:

    1. Entry completion while combobox is editable
    2. Entry completion while combobox is readonly
    3. Selection completion when the list is dropped down

  When in editable mode, you can begin to type text and it will autocomplete the text as you type. When in readonly mode, pressing a key will select an item from the list that begins with that key (case insensitive). When the drop down is visible, pressing a key will select the item from that list that begins with that key (case insensitive). When the drop down is not present (readonly or editable), using your Up/Down arrow keys will cycle through the list values. Pressing Alt-Down in the edit widget (readonly or editable), the drop down list will appear. Pressing Alt-Up while the drop down list is active will update the selection and close the drop down list.

  These are the actions of how the combobox functions on Windows. I am unsure of how comboboxes work on Linux and OS X.


tkt_uuid: 220865ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: obsolete: 8.2
resolution: None
title: Windows/Unix discrepancy, Toplevel -width/-height/-menu
comment:
  OriginalBugID: 2722 Bug
  Version: 8.2
  SubmitDate: '1999-09-10'
  LastModified: '2000-01-17'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3185
  OS: Windows 95
  Machine: X86


  Name:
  Hume Smith

  ReproducibleScript:
  toplevel .x -menu .x.menuBar -width 400 -height 300
      menu .x.menuBar
      
      toplevel .y -width 400 -height 300

  ObservedBehavior:
  On unix, the windows are the same size*
      On Windows'95, .x shrinks to the size of the menubar
      
      (* I hope - I haven't tried this exact code.  It's really Quill's
      windows that behave differently, and it appears to be the -menu option
      that causes the difference.)

  DesiredBehavior:
  I expect the same behaviour on '95 and X... I want both windows the same
      size, as on X


tkt_uuid: 701726ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 85. Win Build
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Borland patches for Tk
comment:
  Hi there,
  I just got the latest sources from SF and with the
  patches applied Tk builds fine. The patches itself are
  really minimal - the diff file is rather long because
  it contains my newest makefile.bc.
  I should maybe add that the identical patches worked
  with T8.4, too, so a 'back-porting' shouldn't be any
  problem.
  Best regards
  Helmut Giese


tkt_uuid: 3281130fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 7 High
foundin: obsolete: 8.5.7
resolution: None
title: tk segfaulting due to Xft fonts
comment:
  Please take a look at 
  http://stackoverflow.com/questions/5488429/tk-segfaults-when-i-use-widget-button-text


tkt_uuid: 1081966fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 8
foundin: obsolete: 8.4.9
resolution: Fixed
title: Slow BMP/JPG image loading by Img
comment:
  The Img extension is very slow to load certain image
  types (BMP, JPG) when they get very large, but not
  others (PNG). This changed between Tk 8.4.8 and 8.4.9,
  and is also true of 8.5a2


tkt_uuid: 1124237fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: Fixed
title: MacOS X Aqua focus and floating windows
comment:
  This bug is specific to MacOS X.  It involves a floating 
  window: the visual effect of this is rather similar to using 
  "wm transient" on Microsft Windows.  After using the 
  floating window, the application loses track of the focus.
   
     ---AppMain.tcl---
  entry .e
  button .b -text Properties -command "popupWindow ."
  pack .e -padx 125 -pady 75
  pack .b -pady 10
  focus .e
   
  proc popupWindow {parent} {
    toplevel .t
    ::tk::unsupported::MacWindowStyle style .t floatGrowProc
    entry .t.e
    button .t.b -text OK -command "destroy .t"
    pack .t.e -padx 75 -pady 10
    pack .t.b -pady 10
    focus .t.e
  }
     ---AppMain.tcl---

  When the main window is created, I can type in the entry 
  box. After clicking on the button, I can type in the new entry 
  in the floating window.  But, after dismissing the floating 
  window, the focus does not return to the entry box on the 
  main window (as it does on Windows, and as it does if I do 
  not use a floating window) and no combination of clicks, key 
  presses or verbal abuse will return the focus to that entry.  
  Another application needs to be brought to the front; 
  AppMain.tcl recovers the focus when it is subsequently 
  returned to the front.

  One workaround is to be explicit about the focus, after 
  destroying the floating window:

  destroy .t; focus -force $parent


tkt_uuid: 220576ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 2
foundin: obsolete: 8.2b2
resolution: Fixed
title: $canvas find enclosed does not find text with trailing newline
comment:
  OriginalBugID: 2525 Bug
  Version: 8.2b2
  SubmitDate: '1999-08-12'
  LastModified: '2000-02-03'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: ericm
  OS: All
  FixedDate: '2000-02-03'
  FixedInVersion: 8.3


  Name:

  Marco R. Gazzetta



  Extensions:

  n.a.



  CustomShell:

  n.a.



  ReproducibleScript:

  pack [canvas .c]

      set item [.c create text 100 100 -text Hello\n -anchor nw]

      set bbox [.c bbox $item]

      set x2 [lindex $bbox 2]

      set y2 [lindex $bbox 3]

      incr y2

      for {set i 1} {$i < 1000000000} {append i 0} {

      puts "$i [.c find enclosed 99 99 [expr $x2 + $i] [expr $y2 + 1]]"

      }



  ObservedBehavior:

  until $i reaches a very large number (hard-coded in tkFont.c), the item

      is not retrieved



  DesiredBehavior:

  the first call (with i == 1) should already return the item searched



  Patch:

  Index: tkFont.c

  ===================================================================

  RCS file: /cvsroot/tk/generic/tkFont.c,v

  retrieving revision 1.5

  diff -c -r1.5 tkFont.c

  *** tkFont.c    1999/06/02 18:15:54     1.5

  --- tkFont.c    1999/08/11 18:13:46

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

  *** 1922,1928 ****

                      continue;

                  }

              } else {

  !               NewChunk(&layoutPtr, &maxChunks, start, 1, curX, 1000000000,

                          baseline)->numDisplayChars = -1;

                  start++;

                  goto wrapLine;

  --- 1922,1928 ----

                      continue;

                  }

              } else {

  !               NewChunk(&layoutPtr, &maxChunks, start, 1, curX, curX,

                          baseline)->numDisplayChars = -1;

                  start++;

                  goto wrapLine;



  PatchFiles:

  tkFont.c





  The problem, as you correctly concluded, was the call to NewChunk and that odd huge number that was passed into it.  This caused the creation of a display element with a large width, rather than one with a zero width as would be expected for a display element containing only a newline.  I applied your patch and corrected another instance of the same mistake later in the same function.

  This fix is in 8.3 final.  Thanks for the patch.

  - eric

  -- 02/03/2000 ericm


tkt_uuid: 2777019fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 8
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: bad anchor on postscript rotated text
comment:
  The (new) rotated text on canvas respect the -anchor option on display, but the postscript output is always rotated from the nw corner.

  This sample script shows the (incorrect) behaviour:
  ===================================

  package require Tk 8.6b1.1
  canvas .c -bg white -width 400 -height 400
  pack .c

  for {set i 1} {$i <= 3} {incr i} {
      set y [expr {$i * 100}]
      .c create line 0 $y 400 $y
      set x [expr {$i * 100}]
      .c create line $x 0 $x 400
  }

  foreach anchor {nw n ne w c e sw s se} \
          {x y}  {100 100 200 100 300 100\
                  100 200 200 200 300 200\
                  100 300 200 300 300 300} {
          
      for {set angle 0} {$angle < 360} {incr angle 90} {
  .c create text $x $y \
          -text abc \
          -angle $angle \
          -font {Courier 18 bold} \
          -anchor $anchor
      }
  }

  after 5000 { .c postscript -file output.ps ; exit }

  ======================================

  compare the on-display and postscript output


tkt_uuid: 592639ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 7 High
foundin: obsolete: 8.4b2
resolution: Fixed
title: remove tcltest dependence - MAC
comment:
  Here's a patch that removes references
  to Tcl's tcltest executable and its components
  from tkMacAppInit.c.  It uses nothing in them.

  There are probably accompanying changes
  that should be made to the build instructions
  on Mac -- whatever is analogous to a
  Makefile -- but I don't know what that is.


tkt_uuid: 1539990fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 41. Photo Images
priority: 9 Immediate
foundin: None
resolution: Accepted
title: Improve speed of Tk_PhotoPutBlock for one-row case
comment:
  In my application, I use tkimg1.3 to load xpm images
  with transparency information.

  I compared the time taken to load the image in
  tk8.2+tkimg1.3 to the time taken in tk8.4+tkimg1.3:
  8.2:          59086 microseconds
  8.4:         769918
  8.4, patched: 77059

  This patch expands the 'single pixel' case into a
  'single span' case: one or more pixels on a single row
  of the image, where all have alpha 0 or 255.  (in fact,
  tkimg1.3's xpm loader always sends spans with fully
  opaque pixels)

  As you can see, this patch reduces the time from 13x as
  long as 8.2 to only 1.3x as long as 8.2.


tkt_uuid: 2837510fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Invalid
title: -displaylines gives unexpected result
comment:
  Please try the following script:
  -------------------------------------------------------
  pack [text .t -width 10 -height 1]
  .t insert end "abc"
  pack [label .l -text [.t count -displaylines 1.0 end]]
  -------------------------------------------------------
  The result "3" is not the number of display lines. The documentation says:
  -------------------------------------------------------
  -displaylines
      count all display lines (i.e. counting one for each time a line wraps) from the line of the first index up to, but not including the display line of the second index. Therefore if they are both on the same display line, zero will be returned. By definition displaylines are visible and therefore this only counts portions of actual visible lines.
  --------------------------------------------------------
  Therefore the result "1" is expected.


tkt_uuid: 879077ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4.6
resolution: Wont Fix
title: Text widget - unexpected tab stop behavior
comment:
  After typing some text, hitting the tab key does not
  always (hardly ever, in fact) move the insert point to
  the next tab stop.

  I've supplied a patch for generic/tkTextDisp.c that
  fixes the problem and gives the expected tabstop
  behavior.  The patch also gives an example so that you
  can reproduce the problem.

  Patch for 8.4.2 is  879073.  Let me know if you want me
  to produce patches for the latest version of Tk.

  --
  Dave Hein


tkt_uuid: 2799589fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 9 Immediate
foundin: obsolete: 8.5.7
resolution: Fixed
title: script crashes Tk on Win systems
comment:
  Chatters on the tkChat confirm that the script
  found at:

  http://paste.tclers.tk/1609?v=raw

  crashes Tk 8.5 programs on Windows systems (XP, Vista).


tkt_uuid: 3608053fffffffffffffffffffffffffffffffff
type: RFE
status: Pending
subsystem: 88. Themed Tk (Ttk)
priority: 5 Medium
foundin: None
resolution: None
title: Allow tristate selection for ttk::checkbuttons
comment:
  At the moment, the only way to get a "tristate" appearance for a checkbutton is to manually unset the variable associated with the widget - it's impossible to get it by interacting with the widget. It would be nice if this was altered, either with
  -tristate <bool>
  which toggles whether clicking the checkbutton can put it into tristate mode (by unsetting the associated variable), probably the better way, or
  -tristate <value>
  which will toggle into tristate mode and set the variable to <value>. If -tristate isn't given, it would not be possible to click into tristate mode.

  When -tristate is given, clicking the checkbutton would toggle it from on -> off -> tristate -> on -> ... etc, rather than just on -> off -> on -> ...

  This would be useful for situations where something can be explicitly on, explicitly off, or ignored, for example when no input is given and the value should be checked on a parent instead.


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

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


tkt_uuid: 3575681fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.5.12
resolution: Works For Me
title: Cocoa 8.5.12 backport still crashes in IDLE clipboard copy
comment:
  With a current Tcl/Tk built from the tk-cocoa-8-5-backport branch on OS and a Python that dynamically links with it, attempting to use clipboard copy in Python IDLE's causes Tk to crash. A more general problem with clipboard copies in Text widgets was reported in #3555211 (https://sourceforge.net/tracker/?func=detail&aid=3555211&group_id=12997&atid=112997) which was addressed in Fossil checkin 2fe193d134 on 2012-08-07 (http://core.tcl.tk/tk/info/2fe193d134).  That checkin resolved some of the crashes but crashes with IDLE still remain.   By the way, it appears that the original clipboard copy regression (as reported in #3555211) was introduced by fossil checkin 90d4b8b59c of 2012-07-25 (http://core.tcl.tk/tk/info/90d4b8b59c).

  The orginial problem documented in #3555211 was first noticed with the release of ActiveTcl 8.5.12.0.  ActiveTcl 8.5.12.1 apparently includes checkin 2fe193d134 and exhibits the problem documented in this issue as still seen with current tip.  The previous ActiveTcl version 8.5.11.1 does not exhibit this problem with IDLE.

  To reproduce, install either the current OS X ActivePython 2.7.2 (http://www.activestate.com/activepython/downloads) or an OS X 64-bit/32-bit python.org python (http://www.python.org/download/), install Tcl and Cocoa Tk 8.5 in /Library/Frameworks, launch IDLE (for example, type /usr/local/bin/idle2.7 in a shell).  Then when the IDLE PyShell menu appears, use the mouse to doubleclick on some text in the PyShell window (for example "copyright"), then use the mouse to select Edit -> Copy from the menu bar.  Using a debug build of Cocoa Tk at current tip (77b3f433c7), the crash occurs at TkpMakeWindow + 465 (tkMacOSXEmbed.c:169). See the attached crash dump.  Further observations:  The crash seems to only occur using the ActivePython 2.7.2 when selecting the Edit->Copy menu item (and not by using its keyboard accelerator Command-C) and only occurs if no other clipboard copies have succeeded; that is, if you use Command-C first, then Edit->Copy does not cause a crash.  Behavior with at least some python.org Python 3.3 (tested with 3.3.0rc1) is different in that the crash occurs using either Command-C or Edit->Copy, unlike 2.7 where only Edit->Copy crashes.

  http://bugs.python.org/issue15574


tkt_uuid: 701931ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 7 High
foundin: obsolete: 8.4.2
resolution: Fixed
title: listbox.test drifts off screen; causes failures
comment:
  The test spinbox-5.7 now fails for the Tk HEAD,
  but not on the core-8-4-branch.

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

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

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

  This is on Linux/Alpha/GNOME.

  Failure (as well as 2 other spinbox test failures)
  seems to only happen during a full `make test`.
  Testing just the spinbox.test file all tests pass.

  Anything in the big geometry manager commit
  that could have caused this?


tkt_uuid: 1462653fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: Out of Date
title: Cascading menus crash on Win98
comment:
  Hello,
  the script below crashes on Win98 under Tcl 8.4.11 and
  (as reported by Pat Thoyts) under 8.4.13 as well - but
  behaves well on Win XP.

  How to reproduce it:
  - Start the program
  - Click on 'Cascade'
  - Go to 'Next cascade' - 3 - 2 - 'Option 1' or 'Option 2'
  - Now without changing the state of the button leave
  the last menu, so that you are "outside" of this app.
  Without touching any other part of the menu hierarchie
  return with the mouse pointer to the first menu
  (displaying 'Next cascade').
  - Move from below into this menu - BOOM.

  Best regards
  Helmut Giese
  ---
  package require Tk
  package require BWidget

  # this fires when a menu gets 'selected'
  proc menuSelect {w} {
      variable GUI
      if { $w ne ".#mnu" || [$w index active] != 1 } {return}
      # update the cascading menu
      # update the count
      $GUI(specM,subCnt) entryconfigure 0 -label 99
      # update the cascade
      for {set val 0} {$val < 3} {incr val} {
          set state [expr {$val ? "normal" : "disabled"}]
          $GUI(specM,subVal${val}Cnt) entryconfigure 0 \
              -label $val -state $state
      }
  }

  # create the main menu (bar)
  set m [menu .mnu -tearoff 0]

  # create the file menu
  set fM [menu $m.file -tearoff 0]
  $fM add command -label "Open" -underline 0
  $fM add command -label "Save" -underline 0
  $fM add separator
  $fM add command -label "Quit" -underline 0

  # create the special menu
  set specM [menu $m.spec -tearoff 0]
  # ... its submenus: one for the count
  set GUI(specM,subCnt) [menu $specM.subCnt -tearoff 0]
  $GUI(specM,subCnt) add command -label ""

  # build the next level of cascading menus
  set GUI(specM,subVal) [menu $specM.subVal -tearoff 0]
  set mItem $GUI(specM,subVal)
  for {set i 0} {$i < 3} {incr i} {
      # create sub-menu for this value
      set subVal${i}Cnt [menu $mItem.subVal${i}Cnt
  -tearoff 0]
      set GUI(specM,subVal${i}Cnt) [set subVal${i}Cnt]
      # this one has a sub-menu, too
      set subVal${i}CntSub [menu $mItem.subVal${i}CntSub
  -tearoff 0]
      set GUI(specM,subVal${i}CntSub) [set subVal${i}CntSub]
      [set subVal${i}CntSub] add command -label "Option 1"
      [set subVal${i}CntSub] add command -label "Option 2"
      # add this sub-sub-menu
      [set subVal${i}Cnt] add cascade -label "" \
          -menu [set subVal${i}CntSub]
      # add the sub menu
      $mItem add cascade -label [expr {$i+1}] \
          -menu [set subVal${i}Cnt]
  }

  # put the special menu together
  $specM add cascade -label "Count" -underline 0 \
      -menu $GUI(specM,subCnt)
  $specM add cascade -label "Next cascade" -underline 0 \
      -menu $GUI(specM,subVal)

  # put everything onto the menubar
  $m add cascade -label "File" -underline 0 -menu $fM
  $m add cascade -label "Cascade" -underline 0 -menu $specM

  # pass on
  . configure -menu $m

  pack [MainFrame .main]
  .main showstatusbar none
  pack .main -fill x -expand yes -side top -anchor n

  # get the frame for the rest
  set f [.main getframe]
  set btn [button $f.btn -text "Click me"]
  pack $btn

  bind $m <<MenuSelect>> [namespace code { menuSelect %W }]


tkt_uuid: 1997907fffffffffffffffffffffffffffffffff
type: Support
status: Closed
subsystem: None
priority: 9 Immediate
foundin: None
title: tk::busy command
comment:
  Hi,

  After some discussions on #tcl, I started adding the BLT busy command to Tk as tk::busy. I've tried to convert as much as possible to the Tcl Object interface. Before writing a TIP I would like to get some feedback as this is my first try at writing a Tk core command.

  Attached the patch created with command

    % cvs -q diff -wuN > busypatch.txt

  based on the head revision.

  Also attached a summary of the commands.

  What's left to be done:

  - man page
  - tests for Tk test suite
  - Mac version?

  Jos.


tkt_uuid: 633300ffffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 39. Image Basics
priority: 6
foundin: None
resolution: None
title: Garbage collection for image
comment:
  There should be a possibility to have images
  automatically deleted when they are no longer used.

  Currently, "image delete" causes the image data to be
  removed immediately, resulting in an empty rectangle if
  the image is used. At the same time, the image will
  stay in memory even if no widget uses it anymore.

  I'd like to request a command "image autocollect <name>
  on/off", which causes the image command to be removed
  when the last instance of the image goes away.


tkt_uuid: 220478ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 58. [send]
priority: 2
foundin: obsolete: 8.1b2
resolution: Fixed
title: Tk doesn't start if Tcl is running
comment:
  OriginalBugID: 1674 Bug
  Version: 8.1b2
  SubmitDate: '1999-03-31'
  LastModified: '1999-04-06'
  Severity: LOW
  Status: Released
  Submitter: pat
  ChangedBy: surles
  OS: Windows NT
  Machine: X86
  FixedDate: '1999-04-06'


  Name:
  Ingemar Hansson

      If tclsh81 is running and I try to start wish81 it hangs until tclsh81
      exits.
      It seems to hang before a new process is created since if I try to start
      wish81 from a command prompt, I don't get the prompt back until tclsh81
      exits and wish starts.
      I'm running Windows NT 4.0 SP4 with NTFS file system
      


  Fixed previously.  04/06/1999 14:42 - surles -


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


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

  Here is the sample script to reproduce the problem.

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


tkt_uuid: 220307ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: wish83 error for gets command
comment:
  OriginalBugID: 5828 Bug
  Version: 8.3
  SubmitDate: '2000-06-06'
  LastModified: '2000-06-06'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All Windows
  OSVersion: NT4.0 SP4
  Machine: Pentium
  ClosedDate: '2000-06-06'


  Name:
  Chang LI

  Extensions:
  Tcl/Tk 8.3

  Comments:
  wish82/83 has a problem to deal with the stdin 
      under windows. I guess it used a fake console
      on Win32 which can only do stdout. These may
      related to the new Tcl/Tk kernel for Windows.

  ReproducibleScript:
  wish82 and wish83 has an error to execute the command:

  %gets stdin
  %

  ObservedBehavior:
  it immediately returned without waiting the input characters.

  DesiredBehavior:
  in tclsh82/83 it is correctly waiting for the input characters
  and accept the character after the return key.



  This is a known issue, and relates to the fact that Window GUI
  apps don't have std console channels.  If you recompile with
  the console flags, it will work, but always pop up a DOS prompt
  to go with this.  There is just a fundamental incompatibility
  between using GUI apps and CLI driven apps. 
  -- 06/06/2000 hobbs


tkt_uuid: 1006286fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 47. Win Fonts
priority: 5 Medium
foundin: None
resolution: Fixed
title: Fix for Win font wrapping bug with leading spaces
comment:
  The attached patch fixes a problem where strings with
  leading
  spaces were being rendered incorrectly because
  Tk_ComputeTextLayout was generating bad results.
  This problem only showed up under Windows in calls to
  Tk_MeasureChars with a max width value failed.


tkt_uuid: 220453ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: International fonts not found automatically
comment:
  OriginalBugID: 1492 Bug
  Version: 8.1b1
  SubmitDate: '1999-03-11'
  LastModified: '2000-04-16'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows 95
  OSVersion: osr2, US English
  Machine: X86
  FixedDate: '2000-04-16'
  FixedInVersion: 8.3.1


  Name: Bill Schongar

  ReproducibleScript:
      pack [canvas .c -width 400 -height 400]
      .c create text 100 100 -text
      "\u6a29\u5229\u306e\u5236\u9650\u306b\u3064\u3044\u3066\uff1a"
      
      Ran wish from default 8.01b1 install
      
      
      Kanji font installed - Bitstream Cyberbit
      Original encoding    - ShiftJIS
      Conversion method    - native2ascii
      Text translation(EN) - "Restricted Rights Notice"
      
  ObservedBehavior:
      There is a 'hang' delay (3-5 seconds of complete unresponsiveness), then
      non-printable ASCII chars appear in the canvas.
      
      If the supporting font is specified directly, response is near immediate
      and the correct local characters appear. Release notes for 8.1 indicate
      that "Tk guarantees to find a way to display any Unicode character
      regardless of the font you selected, as long as there is some font in
      the system that contains the Unicode character." 
      



  DesiredBehavior:
      When characters drawn from the installed BitStream Cyberbit Font, such
      as are shown with:
      
      .c create text 100 100 -font {{Bitstream Cyberbit} 8} -text
      "\u6a29\u5229\u306e\u5236\u9650\u306b\u3064\u3044\u3066\uff1a"
      
      Then the characters appear correctly with no other environment
      (encoding, locale, etc) changes.
      





  The system is probably returning something confusing when describing the font.  We need to write a test program for the user to run that will dump the font attributes so we can see what we are getting.
  03/29/1999 20:51 - stanton -
  --
  Note that 8.3b1 adds "Bitstream Cyberbit" into the default font
  fallback list, so it should be found quickly.  This should be
  tested again with 8.3+ to see if that solves the problem. 
  -- 01/07/2000 hobbs
  8.3 added "bitstream cyberbit" to the fallback which should fix
  the problem in general, but on NT there was a bug that caused fonts
  longer than 16 chars in name length to not get loaded.  This should
  all work as expected for 8.3.1. 
  -- 04/16/2000 hobbs


tkt_uuid: 220212ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 36. [tk_chooseDirectory]
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Invalid
title: Want to have a feature similar to tk_getopenfile
comment:
  OriginalBugID: 2351 RFE
  Version: 8.1
  SubmitDate: '1999-07-16'
  LastModified: '1999-11-16'
  Severity: LOW
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: I'm using tcl/tk built in with Modelsim 5.2
  Machine: X86
  ClosedDate: '1999-11-16'


  Name:
  Mujtaba Hamid

  DesiredBehavior:
  Is there a command which will allow me to select a directory, like
      tk_selectdirectory which i can then connect to a "browse and select
      directory" button? 
      Thanks!



  tk_chooseDirectory is availalbe on Windows. 
  -- 11/16/1999 hobbs


tkt_uuid: 220843ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 20. [tk_optionMenu]
priority: 5 Medium
foundin: final: 8.0.5
resolution: None
title: tk_optionMenu loses grab in dialog
comment:
  OriginalBugID: 2088 Bug
  Version: 8.0.5
  SubmitDate: '1999-05-17'
  LastModified: '1999-05-17'
  Severity: MED
  Status: UnAssn
  Submitter: pat
  ChangedBy: pat
  OS: Windows NT
  OSVersion: 4
  Machine: X86


  Name:
  Yaakov Blank

  ReproducibleScript:
  run the below script. if you click on one of the menu buttons and change
      the value and then try and click on the other menu button the mouse
      click is ignored until you click somewhere else on the dilog box.
      
      This happens approximatly 70% of the time
      ---------------------------------------------------------------   
         set dlgEnd 0
         toplevel .x -class Dialog -width 40
         wm title .x "Format the Reader"
         wm protocol .x WM_DELETE_WINDOW "set dlgEnd 0"
      
         set bb [frame .x.dlgButtons]
         button $bb.b -text "Change" -width 10 -command {set dlgEnd 1}
         pack $bb -side bottom
         pack $bb.b 
      
         tk_optionMenu .x.numeric num one two three four five
         pack .x.numeric -side left -padx 25 -pady 10 -side top
      
         tk_optionMenu .x.alpha abc a b c d e f z
         pack .x.alpha -side left -padx 25 -pady 10 -side top
      
         grab .x
         tkwait variable dlgEnd
         grab release .x
         destroy .x

  DesiredBehavior:
  the menu buttons should react whenever you click on them


tkt_uuid: 581731ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 7 High
foundin: obsolete: 8.4b2
resolution: Invalid
title: crash in windows tk_getSaveFile
comment:
  When using tk_getSaveFile, if the user manoeuvers 
  to a directory which contains a lot of 
  files/directories, it takes a few seconds for the 
  dialog to display everything (and the "searching 
  flashlight" is shown sweeping back and forth).

  If, during those seconds, the user decides to click 
  on 'save' (a perfectly reasonable thing to do if the 
  user wants to save the file in that directory), wish 
  exits immediately, with no warning or error 
  message at all.


tkt_uuid: 548765ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Radiobutton with -value "" drawn badly
comment:
  When creating a radiobutton with -value ""
  it is not drawn properly if the -variable
  was created by the radiobutton.

  pack [radiobutton .rb -variable Apa -value ""]

  The radiobutton is drawn unselected until the
  mouse passes over it.


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

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


tkt_uuid: 220031ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.1
resolution: Invalid
title: a
comment:
  OriginalBugID: 2961 Bug
  Version: 8.1
  SubmitDate: '1999-09-28'
  LastModified: '1999-11-03'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2962
  OS: Other
  Machine: NA
  ClosedDate: '1999-11-03'


  Name:
  Hermann G. Striecks


tkt_uuid: 1995663fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 8
foundin: obsolete: 8.5.2
resolution: Duplicate
title: Fatal Error in Wish
comment:
  The following code will produce a fatal error in Wish (Windows XP, Tcl/Tk 8.52, Tile 0.8.2), when the window is resized.  Details below the code...

  package require tile
  package require tkpng

  image create photo add -data {
      iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABGdBTUEAAK/INwWK6QAAAB
      l0RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAAJvSURBVDjLpZPrS5NhGIf9
      W7YvBYOkhlkoqCklWChv2WyKik7blnNris72bi6dus0DLZ0TDxW1odtopDs4D8MDZuLU0k
      Xq61CijSIIasOvv94VTUfLiB74fXngup7nvrnvJABJ/5PfLnTTdcwOj4RsdYmo5glBWP6i
      OtzwvIKSWstI0Wgx80SBblpKtE9KQs/We7EaWoT/8wbWP61gMmCH0lMDvokT4j25TiQU/I
      TFkek9Ow6+7WH2gwsmahCPdwyw75uw9HEO2gUZSkfyI9zBPCJOoJ2SMmg46N61YO/rNoa3
      9Xi41oFuXysMfh36/Fp0b7bAfWAH6RGi0HglWNCbzYgJaFjRv6zGuy+b9It96N3SQvNKiV
      9HvSaDfFEIxXItnPs23BzJQd6DDEVM0OKsoVwBG/1VMzpXVWhbkUM2K4oJBDYuGmbKIJ0q
      xsAbHfRLzbjcnUbFBIpx/qH3vQv9b3U03IQ/HfFkERTzfFj8w8jSpR7GBE123uFEYAzaDR
      IqX/2JAtJbDat/COkd7CNBva2cMvq0MGxp0PRSCPF8BXjWG3FgNHc9XPT71Ojy3sMFdfJR
      CeKxEsVtKwFHwALZfCUk3tIfNR8XiJwc1LmL4dg141JPKtj3WUdNFJqLGFVPC4OkR4Bxaj
      TWsChY64wmCnMxsWPCHcutKBxMVp5mxA1S+aMComToaqTRUQknLTH62kHOVEE+VQnjahsc
      NCy0cMBWsSI0TCQcZc5ALkEYckL5A5noWSBhfm2AecMAjbcRWV0pUTh0HE64TNf0mczcnn
      Qyu/MilaFJCae1nw2fbz1DnVOxyGTlKeZft/Ff8x1BRssfACjTwQAAAABJRU5ErkJggg==
  }


  foreach btn {.a .b .c .d .e .f .g .h} {
      ttk::button $btn -image add
      pack $btn -side left
  }

  The code will create a horizontal set of ttk buttons in a toplevel window.  Grab the right edge of the window and drag it narrower.  Once the right-most button's entire image is obscured, wish crashes with the following error dialog:

  ---------------------------
  Fatal Error in Wish
  ---------------------------
  unable to alloc 4294967232 bytes
  ---------------------------
  OK   
  ---------------------------

  Interestingly, changing the image to non-PNG-based data does not appear to cause the crash.  Also, it occurs whether using tkpng or img::png.

  Jeff


tkt_uuid: 1954237fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 69. Events
priority: 5 Medium
foundin: None
resolution: None
title: Doubleclick lost if processing click/release slow
comment:
  This problem occurs under Windows XP and MacOS 10.5 when using ActiveTcl 8.5.2. It also occurs on both those OS using various TclTk 8.4.x. It does not occur under Linux.

  Normally if you doubleclick, you get a <Button-1>, <ButtonRelease-1> and <Double-1> event in that order. However, if processing one of the first two takes more than a certain time, the Double event will not be generated at all. 

  This code snippet illustrates the problem; the loop count of 1e7 is right for my 2GHz core 2 duo MacBook. Interestingly if you divide this delay between the click and release events, the double is generated! But put it all on the release, and it is not. 
  ======
  proc delay {n} {
      for {set z 0} {$z < $n} {incr z} {}
  }

  pack [canvas .c]
  .c config -bg beige
  bind .c <Button-1> {delay 10000000; .c config -bg green}
  bind .c <ButtonRelease-1> {delay 0; .c config -bg yellow}
  bind .c <Double-1> {.c config -bg red; puts double}
  ======


tkt_uuid: 220822ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: final: 8.0.5
resolution: Fixed
title: some canvas polygons leave trails when moved
comment:
  OriginalBugID: 2251 Bug
  Version: 8.0.5
  SubmitDate: '1999-06-16'
  LastModified: '1999-08-21'
  Severity: MED
  Status: Assigned
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2426 2250
  OS: Macintosh
  OSVersion: MacOS 8.6
  Machine: Power PC


  Name:
  Michael Halle

  ReproducibleScript:
  Load the canvas item types demo.  Look for the four-pointed star shaped
      object
      in the "polygons" section. Drag it.

  ObservedBehavior:
  Its corners leave trails that are not erased.



  This seems to be a Mac only problem, but it may have to due with
  incorrect calculation in the bounding code for Macs, as exists for
  ovals on Windows (bug 2426). 
  -- 08/21/1999 hobbs


tkt_uuid: 3603077fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: current: 8.6.0
resolution: Fixed
title: ttk::treeview doesn't update display when tags are changed
comment:
  On Windows, a ttk::treeview's display isn't updated when tags are added are removed - you have to move the cursor into (or out of) the treeview for the display to update. Example:

  pack [ttk::treeview .t]
  foreach x [list Foo Bar Baz] {
    .t insert {} end -id $x -text $x
  }
  .t tag configure tagged -foreground yellow -background red
  .t tag add tagged Foo
  .t tag has tagged Foo

  The final command returns 1 as expected, but nothing happens until you move the mouse over the treeview, when suddenly the colors change. Calling [update] doesn't help. 

  Setting an option for the widget does cause it to be automatically redrawn, so in my case I'm doing a no-op like
  .t configure -cursor [.t cget -cursor]
  immediately after changing tags, as a temporary workaround.


tkt_uuid: 3006842fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Fixed
title: Empty binding scripts
comment:
  This may be a very minor windows only bug, but activestate tcl-8.5.8.2 (WinXP) crashes immediately when i assign a null binding to button-1 on a treeview widget, and click on the widget.
  The code that causes it is
    $w.tree tag bind click1 <Button-1> {}
  When using click1 as a tag such as
    $w.tree insert {} 0 -values $values -tag [list click1 click2 treefont]

  Problem is easily solved by removing null binding.

  Sorry for such a shitty bug report, but it may be interesting to someone

  Project is scidvspc , subversion release 42
  http://scidvspc.svn.sourceforge.net/viewvc/scidvspc?view=rev&revision=42


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

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

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

  Input sequence:

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

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

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

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


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

  For example:

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

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


tkt_uuid: 3588936fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 32. Key Symbols
priority: 5 Medium
foundin: obsolete: 8.5.13
resolution: None
title: tkUnixKey.c is wrong for me since 8.5.11
comment:
  Hi,
  on OSX, using unix like Tcl/TK .dylib, since 8.5.11 I cannot acces binding unless I hit a key first.
  with 8.5.13, if I copy/paste code from 8.5.10 tkUnixKey.c and recompile Tk, everything is fine but I doubt it's a good hack.
  here's the link to the discussion on comp.lang.tcl
  https://groups.google.com/d/msg/comp.lang.tcl/8bHk1QKGjFA/ukrgsAQps2QJ

  Best regards,
  Nicolas


tkt_uuid: 220840ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: final: 8.0.5
resolution: Invalid
title: Font configure command choose wrong size
comment:
  OriginalBugID: 1981 Bug
  Version: 8.0.5
  SubmitDate: '1999-05-04'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: pat
  OS: Solaris
  OSVersion: 2.6
  Machine: Other


  Name:
  Oliver Goldman

  Extensions:
  Tcl8.0.5, Tk8.0.5, BLT2.4h, TclX8.0.4, [incr Tcl] 3.0.1

  CustomShell:
  None.

  ReproducibleScript:
  Just try this test:
      
      $ wish8.0
      % font create test -family "lucida sans"
      test
      % font actual test
      -family {lucida sans} -size 10 -weight normal -slant roman -underline 0
      -overstrike 0
      % font configure test -size 10
      % font actual test
      -family {lucida sans} -size 11 -weight normal -slant roman -underline 0
      -overstrike 0
      %

  ObservedBehavior:
  When the font `test' is first created it defaults to size 10 (as
      reported
      by `font actual'). However, after specifically configuring the size to
      10,
      the font instead is of size 11. If the font is in use (say, in a label) 
      this change in size can be visually confirmed.

  DesiredBehavior:
  Since size 10 is available, it should be used.


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


tkt_uuid: 1032077fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: None
resolution: None
title: Add Windows animation of toplevels
comment:
  It would be simple to modify tkWinWm.c:TkpWmSetState to
  use AnimateWindow instead of ShowWindow, based on some
  extra 'wm' params that would allow window animation.


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

  --Alex

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

  +
  char * val;
  +
  Tcl_DString * dstPtr;
  +

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

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

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


tkt_uuid: 220343ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 2
foundin: obsolete: 8.0
resolution: Fixed
title: unintuitive focus behavior
comment:
  OriginalBugID: 565 Bug
  Version: 8.0
  SubmitDate: '1998-04-15'
  LastModified: '1999-08-06'
  Severity: LOW
  Status: Released
  Submitter: hershey
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0
  Machine: NA
  FixedDate: '1999-08-06'
  FixedInVersion: 8.2


  >To: John Ousterhout <ouster@best.com>
  >Subject: Tk bug with <FocusOut>
  >X-Zippy:  So this is what it feels like to be potato salad
  >X-Attribution:  Tom
  >Reply-To: tromey@cygnus.com
  >From: Tom Tromey <tromey@creche.cygnus.com>
  >Lines: 21
  >X-Mailer: Red Gnus v0.34/Emacs 19.34
  >Date: 23 Jan 1998 15:01:23 -0700
  >
  >Here's a little script to demonstrate a problem I found:
  >
  >toplevel .z
  >bind .z <FocusIn> {puts in}
  >bind .z <FocusOut> {puts out}
  >
  >
  >Here's how to reproduce the bug:
  >
  >* Run the script
  >* Click on the toplevel; you should see "in" printed wherever things
  >  are printed (for me, the console I'm using)
  >* Click on the desktop (note nothing happens)
  >* Move the mouse over the "z" window; you should see "out" printed.
  >
  >I think the FocusOut handler should be run as soon as the user clicks
  >on the desktop.
  >
  >Tom

  With 8.2b2, this works as expected (you get the out triggered
  when you click on the desktop), so this was fixed somewhere
  along the way. 
  -- 08/06/1999 hobbs


tkt_uuid: 582457ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 6
foundin: obsolete: 8.4b2
resolution: Fixed
title: checkbutton -overrelief doesn't work
comment:
  I suspect that the addition of the -offrelief may have 
  cause the -overrelief functionality (to make it appear like 
  a new Windows-style toolbar button) to not work.  
  Regular buttons still work fine.  Did not check 
  radiobuttons.  This is 8.4b1 on Windows2000.


tkt_uuid: 3009998fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 01. Bindings
priority: 8
foundin: None
resolution: Accepted
title: Binding procedure reform
comment:
  Attached patch winscrollbar-bindproc replaces the TkBindEvalProc ScrollbarBindProc with an ordinary event handler.

  (Description to follow).


tkt_uuid: 1170803fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 02. Appearance
priority: 8
foundin: None
resolution: Accepted
title: DrawThemeButton patch for OS X
comment:
  I just rewrote the tkMacOSXButton.c part of my Theme patches, to 
  use DrawThemeButton(), to properly get Focus halos, etc. around 
  buttons.  Doing so, I managed to reduce the size of the .c file from 
  55k to 36k.  It simplifies the code, makes focus halos work, and 
  uses proper Theme calls.  The only downside I can see is that '-
  default active' buttons won't actually pulse.  :/  Apparently 
  DrawThemeButton() doesn't have support for that in it's API yet.  
  This change is completely independent of my pinstripe patches, so 
  the file can be dropped into stock Tk just fine.


tkt_uuid: 1186643fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4.7
resolution: Out of Date
title: double click is not handled correctly
comment:
  checkbutton - chooseFile conflikt: 
  double click in tk_getOpenFile Dialog chooses a file
  and closes the dialog window, but at the same time or
  afterwards the checkbox laying at a position behind the
  dialog window is activated.
  The double click event should complete eaten up by the
  openFile dialog, but instead the checkbutton widget
  gets a mouse click event too.

  ActiveTcl 8.4.7 on Windows 2000 SP 3


tkt_uuid: 923555ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 6
foundin: obsolete: 8.5a1
resolution: Fixed
title: [image data -format] ignores old image formats
comment:
  Lines 937-946 of tkImgPhoto.c loop
  through the photo image formats
  on the formatList seeking one which
  will support the -format.

  There's no following loop through
  the oldFormatList.  This means if
  the requested -format is implemented
  via either.

      Tk_CreateOldPhotoImageFormat()

  or
   
      #define USE_OLD_IMAGE
      Tk_CreatePhotoImageFormat()

  then it's offered stringWriteProc will
  just be ignored.

  This bug may have been around since
  the change in photo image formats (8.2?).

  We might have caught it, except none of
  the built-in photo image formats supports
  a stringWriteProc, and thus we have no
  tests of the [image data -format] command.


tkt_uuid: 646382ffffffffffffffffffffffffffffffffff
type: Support
status: Closed
subsystem: None
priority: 5 Medium
foundin: None
title: TIP#116 Sample Implementation
comment:
  Sample implementation of scheme to get rid of panic()
  from everywhere in normal use of the photo image system.
  See http://purl.org/tcl/tip/116 for details.


tkt_uuid: 3501372fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 29. Colormaps and Visuals
priority: 5 Medium
severity: Minor
foundin: obsolete: 8.5.10
resolution: None
title: Washed out colors on Mac OS X display
comment:
  While building a Tk app in Python on Mac OS X 10.7.3, I noticed the colors appear consistently "washed out" as if there is some sort of bad gamma correction going on under the hood. As a test, I write a very simple app that draws 1-pixel-high rectangles to a canvas with varying levels of intensity on each of the RGB channels, creating a black-to-white gradient.

  Second, I created a black-to-white gradient in GIMP to use as a baseline. When placed side-by-side, it's pretty clear that Tk is adjusting colors incorrectly.

  I've tried the same test on Linux, and it appears to work correctly, displaying the same exact gradient as generated by GIMP. I have also tried updating ActiveTcl and Python on OS X, but the problem persists. I'm now using python.org Python 2.7.2, and ActiveTcl 8.5.11.1.

  Attached is a PNG that illustrated the difference between the Tk gradient and the GIMP gradient, as well as the Python source I used to generate the Tk gradient.


tkt_uuid: 2961564fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 45. Aqua Fonts
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Wont Fix
title: No italic TkDefaultFont in Tk Cocoa
comment:
  Making a label with font TkDefaultFont and italic slant displays a non-italic font with Tk Cocoa 8.6, Jan 8, 2010 source code.  With Tk 8.5.8 Aqua (Carbon) an italic font is shown.  The default Tk Cocoa font should have an italic version.

  Here's a Wish script demonstrating the problem:

  label .l -text "in italics?" -font "TkDefaultFont 13 italic"
  puts [font actual {TkDefaultFont 13 italic}]
  pack .l

  On Tk Cocoa 8.6 this shows a non-italic label and prints the following actual font being used:

  -family {Lucida Grande} -size 13 -weight normal -slant roman -underline 0 -overstrike 0

  On Tk Aqua (Carbon) 8.5.8 the displayed label is italic and the script prints the actual font as:

  -family Geneva -size 13 -weight normal -slant italic -underline 0 -overstrike 0

  Both tests were run on Mac OS 10.6.2.


tkt_uuid: 220653ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: obsolete: 8.3b2
resolution: Fixed
title: string args bug from UTS4 C compiler
comment:
  OriginalBugID: 4027 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-17'
  LastModified: '2000-01-18'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Other
  OSVersion: UTS4
  Machine: Amdahl ??
  FixedDate: '2000-01-18'
  FixedInVersion: 8.3


  Name: John Ellson

  ObservedBehavior:
  cc -c -O    -I. -I./../generic  -I./../bitmaps -I/opt2/exp/expmake/build/tcltksrc/tcl8.3/generic   -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_PW_GECOS=1 -D__CHAR_UNSIGNED__=1       -DTCL_NO_DEPRECATED   ./../generic/tkListbox.c

  "./../generic/tkListbox.c", line 2517: Syntax error: stringRep
  2517        "number", (char *)NULL);
  ____________________________^
  "./../generic/tkListbox.c", line 2525: Syntax error: stringRep
  2525        "number", (char *)NULL);
  ____________________________^
            ./../generic/tkListbox.c ... 2 Errors.

  DesiredBehavior:
  no compile errors

  Patch:
  *** generic/tkListbox.c.origSun Jan 16 12:36:54 2000
  --- generic/tkListbox.cSun Jan 16 12:37:29 2000
  ***************
  *** 2513,2528 ****
    strtol(start, &end, 0);
    if ((start == end) || (*end != ',')) {
        Tcl_AppendResult(interp, "bad listbox index \"", stringRep,
  !     "\": must be active, anchor, end, @x,y, or a "
  !     "number", (char *)NULL);
        return TCL_ERROR;
    }
    start = end+1;
    y = strtol(start, &end, 0);
    if ((start == end) || (*end != '\0')) {
        Tcl_AppendResult(interp, "bad listbox index \"", stringRep,
  !     "\": must be active, anchor, end, @x,y, or a "
  !     "number", (char *)NULL);
        return TCL_ERROR;
    }
    *indexPtr = NearestListboxElement(listPtr, y);
  --- 2513,2528 ----
    strtol(start, &end, 0);
    if ((start == end) || (*end != ',')) {
        Tcl_AppendResult(interp, "bad listbox index \"", stringRep,
  !     "\": must be active, anchor, end, @x,y, or a number",
  !                     (char *)NULL);
        return TCL_ERROR;
    }
    start = end+1;
    y = strtol(start, &end, 0);
    if ((start == end) || (*end != '\0')) {
        Tcl_AppendResult(interp, "bad listbox index \"", stringRep,
  !     "\": must be active, anchor, end, @x,y, or a number",
  !                     (char *)NULL);
        return TCL_ERROR;
    }
    *indexPtr = NearestListboxElement(listPtr, y);

  PatchFiles:
  generic/tkListbox.c



  Although this is obviously a compiler bug (and serious, since this
  is a basic C tenant), the fix was made in the code. 
  -- 01/17/2000 hobbs
  Correction, this is not a compiler bug, it is ANSI C behavior,
  which we don't (yet) require.  For the UTS compiler, this is
  received by adding either -Xa or setting CC=$(ANSICC). 
  -- 01/18/2000 hobbs


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

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

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

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


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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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


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

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

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



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

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

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


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

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

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



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

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

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


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

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

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



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

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

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


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

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

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



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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


tkt_uuid: 220030ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 1 Zero
foundin: obsolete: 8.2
resolution: Duplicate
title: segfault when you call destroy
comment:
  OriginalBugID: 2959 Bug
  Version: 8.2
  SubmitDate: '1999-09-28'
  LastModified: '1999-11-04'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hershey
  RelatedBugIDs: 2725
  OS: Solaris
  OSVersion: 5.5.1 Generic_103640-24 sun4u sparc SUNW,Ultra-1
  Machine: Other
  ClosedDate: '1999-11-04'


  Name:
  Philippe KERLIRZIN

  ReproducibleScript:
  > /usr/local/packages/tcltk8.2/bin/wish8.2
      % scale .s -cursor watch
      .s
      % destroy .s
      Segmentation fault (core dumped)
      >


tkt_uuid: 593646ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: Out of Date
title: wish can't open library: libtk8.4.dylib
comment:
  I am running MacOS X 10.1.5 with tk8.4b1. The make and make 
  install appear to run correctly. I set the configure prefix to /sw. If I 
  run /sw/bin/wish8.4 from my user directory I get "wish8.4 can't 
  open library: libtk8.4.dylib. If I run /sw/bin/wish8.4 from the src 
  directory /sw/src/tk8.4b1/unix, wish works. This directory contains 
  libtk8.4.dylib.It appears that the install did not set up wish 
  correctly to find libtk8.4. The install did create a /sw/lib/
  libtk8.4.dylib file which the correct permissions. 


tkt_uuid: 556259ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Fixed
title: Tk_PhotoPutBlock() and alpha
comment:
  Tk_PhotoPutBlock() does not handle alpha very well.
  - First, it does a memcpy() where it should not (it
  should never).
  - Second, when copying into unassigned pixels (alpha of
    destination is 0), destination pixels are initialized
  with 0xd9.
    Why not just copy (not blend) the source ?

  Also, it would be nice to update comment that says
  "24 bits per pixel" and pix24 field of PhotoMaster
  struct.

  There is also an problem with [image put] command. With
  internal format, you can do:
    $image put #000000 -to 0 0 50 50
  to fill all these pixels, but you can't with a user
  defined format,
  since Tk_ImageStringReadProc receives width and height
  of its
  data bounded to the -to area.
  This can be solved by setting width and height to the
  -to area
  (line 1010-1015 of tkImgPhoto.c), but I don't know the
  side effect
  on existing format handler.


tkt_uuid: 3607830fffffffffffffffffffffffffffffffff
type: Bug
status: Pending
subsystem: 32. Key Symbols
priority: 9 Immediate
foundin: obsolete: 8.5.13
resolution: Fixed
title: XkbKeycodeToKeysym fails sometimes
comment:
  The XkbKeycodeToKeysym call cannot always be used if the X server does not support it.  A run time check is necessary before using this call.  If the X server does not support the extension, this call will return NoSymbol for some keys, depending on the particular server and keyboard setup.

  I have seen this behavior on different configurations, but I have not been able to determine exactly what's different about the setup.  However, in all cases, absence of the extension is true (test `xdpyinfo | grep XKEYBOARD` || echo bad) when the call fails.  Unfortunately, the inverse is not true, i.e., the xkb call does work in some cases where the extension is not present. 

  I'm currently working on a patch that will verify the existence of the extension first, when the Display is opened, and then use the appropriate (old or new) call as required.  If you think about it, this makes sense since the server is not necessarily on the build/installation machine, so this has to be a runtime decision, not a compile time decision.

  Please stay tuned...


tkt_uuid: 1601494fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 50. [pack]
priority: 5 Medium
foundin: obsolete: 8.4.14
resolution: Invalid
title: Strange behavior in pack and configure
comment:
  The behavior of the packer is extremely odd when a packed expandable widget has its geometry reconfigured.  What I had intended to do in the following code was to make the .yes button's current width 200 pixels, but that's not anything close to what happens.  Run the attached script to see for yourself.  I was using Tcl/Tk 8.4.14.


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


tkt_uuid: 688572ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Minor message formatting fix
comment:
  Literal \n strings appear in the "File xxx already 
  exists.\n\nReplace existing file" message generated by the 
  save dialogue.

  Use quotes instead of curly braces to cure.


tkt_uuid: 950095ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 73. Argv Parsing
priority: 5 Medium
foundin: None
resolution: Fixed
title: CONST-ify fields of Tk_ArgvInfo, (etc.)
comment:
  From casual observation, it seems like most of the fields of 
  Tk_ArgvInfo can be const pointers -- there is no obvious 
  need for Tk to ever overwrite them. Am I wrong, and the 
  code like 
   
  static Tk_ArgvInfo argTable[] = { 
      {"-file", TK_ARGV_STRING, (char *) NULL, (char *) 
  &fileName, 
  "File from which to read commands"}, 
   [...] 
  } 
   
  needs to pass -fwritable-strings to the compiler? 
   
  If I am right, should the typedef be modified? Thanks! 


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


tkt_uuid: 220602ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 2
foundin: obsolete: 8.2
resolution: Fixed
title: wish panics on bad command line arguments
comment:
  OriginalBugID: 3052 Bug
  Version: 8.2
  SubmitDate: '1999-10-06'
  LastModified: '1999-11-02'
  Severity: MED
  Status: Released
  Submitter: stanton
  ChangedBy: hobbs
  RelatedBugIDs: 1472
  OS: All Windows
  FixedDate: '1999-11-02'
  FixedInVersion: 8.2.2


  In WinMain, when an error occurs during initialization, it calls WishPanic to display the message.  This is inappropriate because WishPanic calls DebugBreak().  WinMain should display a message box directly and then cleanly exit with an appropriate return code instead.



  Fixed for 8.2.2. 
  -- 11/02/1999 hobbs


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

  Reminder to examine this in detail later.


tkt_uuid: 1088816fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 07. [entry]
priority: 2
foundin: obsolete: 8.5a3
resolution: None
title: Aqua tests fail
comment:
  ==== entry-1.33 configuration options FAILED
  ==== Contents of test case:

          .e configure $name $goodValue
          list [lindex [.e configure $name] 4] [.e cget
  $name]
      
  ---- Result was:
  0 0
  ---- Result should have been (exact matching):
  1 1
  ==== entry-1.33 FAILED
  ==== entry-13.10 GetEntryIndex procedure FAILED
  ==== Contents of test case:

      # On unix, when selection is cleared, entry
  widget's internal 
      # selection range is reset.

      list [catch {.e index sel.first} msg] $msg

  ---- Result was:
  0 1
  ---- Result should have been (exact matching):
  1 {selection isn't in widget .e}
  ==== entry-13.10 FAILED

  ++++ entry-13.11 SKIPPED: win
  ---- entry-13.12 start

  ==== entry-13.12 GetEntryIndex procedure FAILED
  ==== Contents of test case:

      list [catch {.e index sbogus} msg] $msg

  ---- Result was:
  1 {bad entry index "sbogus"}
  ---- Result should have been (exact matching):
  1 {selection isn't in widget .e}
  ==== entry-13.12 FAILED


tkt_uuid: 747814ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 9 Immediate
foundin: None
resolution: Fixed
title: Typographical error in panedwindow man page
comment:
  The panedwindow man page appears to have a minor 
  typograpical error.  In the string quoted below, the 
  word "and" is probably intended to be just "an".

     When adding a new window that has not 
     yet been mapped, and update idletasks 
     call is required for that window 


tkt_uuid: 220070ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: final: 8.2.3
resolution: Duplicate
title: --enable-threads slows down all Tcl/Tk apps
comment:
  OriginalBugID: 4261 Bug
  Version: 8.2.3
  SubmitDate: '2000-02-28'
  LastModified: '2000-02-28'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 2438
  OS: Linux
  OSVersion: Slackware Linus v7.0 (problem als present under Slackware v4.0 w
  Machine: Cyrix 6x86L-PR200 (home-built)
  ClosedDate: '2000-02-28'


  Name:
  Kevin D. Knerr, Sr.

  Extensions:
  TclX v8.2.0

  CustomShell:
  none

  Comments:
  I raised this issue on the TkRat list and was advised to compile Tcl w/o
      --enable-threads. One of the responses included the following
      confirmation:

      On 28 Feb, Robert Newcater wrote:
      > Kevin,
      > 
      > I can confirm that this also works for Tc/Tk 8.3 -- mainly for the
      benefit of others, but it's your thread  :-)
      > 
      > I also noticed this slowness when using Tcl/Tk 8.3 and TkRat 2.0b9.
      When I had TkRat running, I noticed that CPU usage by TkRat was between
      40% and 60% and that letters appeared on screen quite slowly (on a PII
      350 with 128 MB RAM).  I had also compiled Tcl/Tk with --enable-threads
      at the configure stage.
      > 
      > Recompiling Tcl/Tk without the --enable-threads parameter and then
      recompiling TkRat soved the problem.
      > 

      A further reply noted that threads are not supported in wish and that a
      bug-report should be filed with Scriptics. (Hence this bug report ;-)

      In the stupid question department, if wish doesn't support threads, why
      is there an "enable-treads" option in the first place? Nor is there
      anything that I found in reading the INSTALL/README items that would
      suggest that enabling threads would be a bad idea, even if I had a
      kernel which supported threads.

      If this is not an easily fixable bug (and I suspect that it's not--it
      might well have been present throughout the 8.x series), could you at
      least update the installation info regarding the circumstances under
      which it is advisable to use --enable-threads? TIA

  ReproducibleScript:
  compile tcl 8.2.x/8.3 with --enable-threads on a system w/ thread-safe Xlibs, such as XFree86 3.3.x or better.
  invoke just about any tcl/tk app that uses extensive text input -- such as TkRat v2.0bx

  ObservedBehavior:
  watch your system slow to a crawl as you try to type a simple 4 line email :-(

  DesiredBehavior:
  system responsiveness commesurate with my system specs, as modified by cpu load


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

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

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

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

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

  mfg

  aotto


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

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

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

  The actual cause of CharUpperA's failure is unclear.

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

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

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

  A minimal testcase:

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

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


tkt_uuid: 228444ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Works For Me
title: Can't enumerate font families on Windows NT/2000
comment:
  The initialization of the Tk system creates the application window before calling TkpInit().

  On windows, TkpInit() calls TkWinXInit(), which initialises the tkPlatformId variable. However, the font system is initialised during creation of the application window, and it uses this variable.

  In tkWinFont.c, in function TkpFontPkgInit(), the systemEncoding variable is set to unicodeEncoding, if the value of tkPlatformId is VER_PLATFORM_WIN32_NT. However, since this is done before the tkPlatformId variable is set up, the systemEncoding variable remains set to NULL.

  Later on, if you enumerate the fonts families (which calls TkpGetFontFamilies on windows), it determines that it is on NT (since the value of tkPlatformId is set up by this point), and calls the unicode version of EnumFontFamilies. 

  This calls the callback function with a unicode string, but the systemEncoding variable is still NULL, so the strings don't get decoded properly. What you actually get is the first character of each of the font families.

  This also means that you can't set fonts properly using the form {Courier -size 8}.

  I have patched this on my system as follows (in win/tkWinX.c):

  Near the top:
  > static int tkPlatformId=-1;

  Later on:
  > int TkWinGetPlatformId()
  > {
  > if (tkPlatformId==-1) {
  > OSVERSIONINFO os;
  > GetVersionEx(&os);
  > tkPlatformId = os.dwPlatformId;
  > }
  > return tkPlatformId;
  > }


tkt_uuid: 226945ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 30. Color Names
priority: 5 Medium
foundin: obsolete: 8.3.2
resolution: Invalid
title: RGB color built-ins are incorrect
comment:
  If you do a man on colors, you will see the RGB values associated
  with the color names known internally by Tk.  Unfortunately, the
  values in the man page appear to not be typos!  The colors really
  are that bad.  I'm not sure who's rgb.txt file these colors came
  from, but they're horribly incorrect.  I haven't seen RGB values this
  bad in years.  I suggest updating the built-in color definitions.

  I will see about submitting a patch shortly.... ick....they're really
  bad.  I'm curious, where did they come from??


tkt_uuid: 220046ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: None
priority: 1 Zero
foundin: None
resolution: Duplicate
title: Expect_tk doesn't initialize Tk's stub table
comment:
  OriginalBugID: 3646 Bug
  Version: 8.3b1
  SubmitDate: '1999-11-23'
  LastModified: '2000-01-20'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 4029
  OS: All
  ClosedDate: '2000-01-20'


  Name:

  Jan Nijtmans


  CVS:

  6 Nov 1999


  Extensions:

  Expect (from Scriptics CVS), Img 1.2.2


  Comments:

  The function TkCreateFrame needs to be called by any extension, therefore this is

  the most appropriate place to do the Tk stub table initialization. The Tcl stub table

  needs to be initialized in the first Tk function called, which could be either

  Tk_ParseArgv() or TkCreateFrame(). In order to be sure in all situations,

  better do it in both of them.


  Because more extensions than Expect might have the same

  problem the best place to fix this is in Tk, even though Expect

  is the actual cause of this problem.


  The same problem is present in Tk 8.1.x and 8.2.x as well.


  ReproducibleScript:

  Try to load any stub-enabled extension based on Tk (e.g. Img) in expect_tk. The

  result of this is either a crash, either a message that this version of Tk doesn't

  support Stubs.

  Explanation: Expect_tk doesn't call Tk_Init() nor Tk_MainEx(), which do the

  main work of initializing the Stub tables. Solution: Add the required initialization

  to the function TkCreateFrame() and Tk_ParseArgv() too.


  Patch:

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

  --- generic/tkArgv.cSun Nov 14 16:27:00 1999

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

  *** 91,96 ****

  --- 91,100 ----

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

        int i;


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

  + return TCL_ERROR;

  +     }

  + 

        if (flags & TK_ARGV_DONT_SKIP_FIRST_ARG) {

    srcIndex = dstIndex = 0;

    argc = *argcPtr;

  *** generic/tkFrame.c.origTue Aug 10 07:06:01 1999

  --- generic/tkFrame.cSun Nov 14 16:32:27 1999

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

  *** 223,229 ****

    /*

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

     *

  !  * TkFrameCreate --

     *

     *This procedure is invoked to process the "frame" and "toplevel"

     *Tcl commands;  it is also invoked directly by Tk_Init to create

  --- 223,229 ----

    /*

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

     *

  !  * TkCreateFrame --

     *

     *This procedure is invoked to process the "frame" and "toplevel"

     *Tcl commands;  it is also invoked directly by Tk_Init to create

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

  *** 238,243 ****

  --- 238,244 ----

     *

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

     */

  + extern TkStubs tkStubs;


    int

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

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

  *** 261,264 ****

  --- 262,269 ----

        unsigned int mask;

        Colormap colormap;

        Visual *visual;

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

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

  + return TCL_ERROR;

  +     }


  PatchFiles:

  tkArgv.c tkFrame.c


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

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

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

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

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

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

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

  Thanks in advance,
     Dmitry Samborsky, Moscow


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

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

  This problem does not happen with the Tcl makefile.

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


tkt_uuid: 1023955fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: None
resolution: Fixed
title: don't flip cursor on menus
comment:
  On unix, the cursor flips to 'arrow' when you click in
  a menu.  This is adopted from Motif, and no other unix
  toolkit seems to use this style anymore.  Those kind of
  things belong in the tk_strictMotif paradigm, if we
  retain them at all.  The attached patch corrects that.


tkt_uuid: 220405ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 35. [tk_dialog]
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: tk_dialog's font is hardcoded to a non-system-default one (Times 18) on Unix and Windows
comment:
  OriginalBugID: 911 RFE
  Version: 8.0.3
  SubmitDate: '1998-12-04'
  LastModified: '1999-08-15'
  Severity: MED
  Status: Released
  Submitter: welch
  ChangedBy: hobbs
  OS: HP-UX
  OSVersion: 10.20
  Machine: Other
  FixedDate: '1999-08-15'
  FixedInVersion: 8.2


  Name:

  Akos Polster


  Extensions:

  [incr Tcl], TclX


  CustomShell:

  No


  DesiredBehavior:

  Do not explicitly set the dialog's 

  font if not running on Macintosh.


  Patch:

  *** dialog.tcl.old      Tue Nov 17 12:28:51 1998

  --- dialog.tcl.new      Tue Nov 17 12:29:14 1998

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

  *** 68,75 ****

        label $w.msg -justify left -text $text

        if {$tcl_platform(platform) == "macintosh"} {

          $w.msg configure -font system

  -     } else {

  -       $w.msg configure -font {Times 18}

        }

        pack $w.msg -in $w.top -side right -expand 1 -fill both -padx 3m -pady 3m

        if {$bitmap != ""} {

  --- 68,73 ----


  PatchFiles:

  library/dialog.tcl




  This was changed to use the option mechanism so the font can be
  overridden by the programmer.  The class value is *Dialog.msg.font. 
  -- 08/15/1999 hobbs


tkt_uuid: 608115ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 7 High
foundin: obsolete: 8.4.0
resolution: Fixed
title: Tk virtual events not documented
comment:
  The initialization script of Tk, $tk_library/tk.tcl,
  defines
  several virtual events with the [event add] command.
  Effective users of Tk need to know what these events
  are, but they are not documented.


tkt_uuid: 597432ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: None
resolution: Fixed
title: Tk Build Doesn't Check for Proper Tcl
comment:
  Tk doesn't check for the proper tcl header or configuration.  
  I fetched the CVS head of tcl and tk.  I created a tcl_build 
  directory then ran ../tcl/unix/configure && make.  Tcl built 
  properly.  Then I ran cp -R tk mod_tk and tried to build tk 
  from the mod_tk/unix directory.  I found that tclDecls.h wasn't 
  working, because it was using an older tcl.  Obviously I 
  should have used --with-tcl when configuring Tk, but it seems 
  like some sort of warning should have been displayed about 
  it not finding the proper Tcl version to build with.


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


tkt_uuid: 1373712fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 32. Key Symbols
priority: 8
foundin: obsolete: 8.5a4
resolution: Fixed
title: XIM does not work when %A is in binding
comment:
  Consider the following examples:

  entry .x
  pack .x
  bind .x <Key> { puts "Key %A"; }

  #and

  text .y
  pack .y
  bind .y <Key> { puts "Key %A"; }

  They both result in corresponding widget being
  displayed; when I confirm a character in XIM's dialog
  and it should get inserted, nothing is displayed. If I
  access widgets contents, it is empty. But on the
  terminal all corresponding "Key ..." strings are printed.

  However, cutting-and-pasting works for the same characters.

  In opposite, if I use the following scripts, widgets
  behave completely as expected and XIM works fine:

  entry .x
  pack .x
  bind .x <Key> { puts "Key"; }

  #and

  text .y
  pack .y
  bind .y <Key> { puts "Key"; }

  I only have a Debian "etch" Linux system to test this
  behaviour. It is stably reproducible.

  Danya.


tkt_uuid: 3234167fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: None
title: Image and font problems on Tk Cocoa Buttons
comment:
  Last-CVS Tk.

  Image button displays the image off-center and if border width 0 will obscure one pixel around the image.
  Text buttons, if the font is set, seem to be setting their size based on the point size rather than querying the font's metrics.
  These problems are specific to Tk Cocoa and do not occur under Tk Carbon.
  The following script reproduces, and the attached zip contains the image and screenshots of the results.


  #!/usr/bin/wish

  # Reproduce Tk-Cocoa button issues
  # Last-CVS version as of 2011-03-22

  set searchButtonImg [image create photo -file "searchButton.gif"]

  toplevel .l
  wm title .l [expr { $tcl_platform(pointerSize) == 8 ? "Cocoa" : "Carbon" }]

  frame .l.i
  frame .l.t

  button .l.i.b1 -image $searchButtonImg -borderwidth 0
  button .l.i.b2 -image $searchButtonImg -borderwidth 1

  set cfont [font create -family 华文楷体 -size 24]
  set tfont [font create -family Courier -size 24]
  button .l.t.b1 -font $cfont -text "华文楷体"
  button .l.t.b2 -font $tfont -text "Courier"

  pack .l.i.b1 -padx 10
  pack .l.i.b2 -padx 10

  pack .l.t.b1 -padx 10
  pack .l.t.b2 -padx 10

  pack .l.i -pady 10
  pack .l.t -pady 10


tkt_uuid: 928527ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 65. Generic Window Operations
priority: 5 Medium
foundin: None
resolution: Out of Date
title: determining if a window has been raised or lowered
comment:
  I just spent a day try to figure out the following:
  I have a main window and multiple other smaller
  configuration windows that are open in parallel to the
  main window. The following behaviour of the main window
  would be good:
  * iconize main window -> all config windows disappear
  * de-iconize window -> config windows reappear
  * move main window -> config windows move also
  * lower main window -> config windows lower themselves also
  * raise main window -> config windows also raise

  The points 1 and 2 can be done (e.g. using the wm group
  command). The 3rd point can be done with the help of
  the binding to the Configure-event.
  But it seems there is no direct way of determining if a
  window has explicitly been raised or lowered. (It seems
  no explicit event is sent for the event of changing the
  stacking order on the X winow system. I verified this
  with using /usr/X11R6/bin/xev). 
  Two events are sent, though: VisibilityNotify and
  Expose. But they are sent in other cases also. 

  It seems the only way to determine if a window has been
  raised or lowered is to know its index and/or
  neighbouring windows in the stacking level list. This
  list is attained by (recursively) calling the
  XQueryTree function.

  I tested the idea and it works well.

  my suggestion:

  adding a funtion to the winfo command:
  &nbsp;&nbsp;winfo stacklevel $windowid
  returns the stacklevel of a window

  and
  &nbsp;&nbsp;winfo stacklevel $windowid -get prevneighbour
  &nbsp;&nbsp;winfo stacklevel $windowid -get nextneighbour
  returns the window ids of the previous and next neighbours

  (calling winfo stacklevel without a windowid could
  return the complete list of all window ids...)

  I could supply a patch.


tkt_uuid: 411307ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.4a2
resolution: Fixed
title: event generate can crash
comment:
  In tkBind.c:HandleEventGenerate handling of options -
  above, -root, -subwindow and -window make use of 
  NameToWindow to parse the window specification. 
  NameToWindow CAN return TCL_OK with a NULL tkWin 
  pointer (this happens when a window id is given which 
  does not refer to a Tk window). Unlike in the handling 
  of objv[0], however, the option handling core does not 
  check for this case.

  There should supposedly be a NameToWindowId helper 
  function anyway, since the returned Tk window pointer 
  is only used to look up the window id anyway in the 
  option handling code.

  The bug struck me when I tried to generate an event 
  from a binding, trying to forward %R with -root.


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

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


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

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

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

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


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


tkt_uuid: 733603ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 5 Medium
foundin: None
resolution: Invalid
title: XGetSelectionOwner bug in wish8.3
comment:
  This is a bug report for wish8.3.  According to the
  Inter-client  
  communication conventions manual (ICCCM, version 2.0),  
    
    After calling \code{XSetSelectionOwner}, selection
  ownership must be verified by calling
  \code{XGetSelectionOwner}. 
    
  Violating this rule could cause the user to be misled
  about which 
  window owns the selection.  The routine Tk_OwnSelection
  (from generic/tkSelect.c) violates the rule: 
  it doesn't call XGetSelectionOwner. 
   
  Submitted by Glenn Ammons (ammons@cs.wisc.edu).


tkt_uuid: 2671711fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 33. Generic Dialog Support
priority: 5 Medium
foundin: None
resolution: Rejected
title: KDE openfiledialog bug
comment:
  When openfiledialog is launched in KDE, it will launch the KDE openfiledialog, and will let you browse dirs and select files. BUT, if dir's name contains special characters like "`" it wont let you open the dir. Example:

  "DirName1" > will let you open the folder and select file(s).

  "DirNáme1" > WONT let you open the folder.


tkt_uuid: 2971762fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.5.8
resolution: Duplicate
title: grid-pack interaction hangs interpreter
comment:
  The following code hangs the interpreter it is executed in, and causes the CPU to peg permanently at 100%.  Sometimes it hangs my entire computer, though I can't repeat that behavior reliably.  I'm using ActiveTcl 8.5.8 on Ubuntu Intrepid with the default Gnome desktop.

  package require Tk
  toplevel .gridpack
  label .gridpack.grid -text grid
  label .gridpack.pack -text pack
  grid .gridpack.grid
  pack .gridpack.pack


tkt_uuid: 2824550fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: Tk crashes after destroying a widget
comment:
  Tk crashes with the following message : 

  malformed bucket chain in Tcl_DeleteHashEntry
  Aborted

  Problem is 100% reproducible with tk 8.5.0-3 Ubuntu build and Tk8.5.7 (stable) version built from the source.
  To reproduce : launch the provided script, and then left click the combobox in the middle of the widget. It always crashes at the 2nd click here.


tkt_uuid: 2838812fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 68. Win Window Operations
priority: 7 High
foundin: None
resolution: None
title: Multi-purpose patch: fixes bug#1391053, adds wm attrs.
comment:
  Bug#1391053: spurious events generated on Windows after completion of tk_getOpenFile, tk_chooseColor and similar modal dialogs.  This patch, redone against CVS head, provides a real solution for this long-standing problem, instead of the current pseudo-solution that hurts but not helps (see win/tkWinDialog.c:EatSpuriousMessageBugFix).

  Steps to reproduce: (1) bind . <1> "puts Click"; bind . <3> tk_getOpenFile; maximize main window; right-click, then select a file. When the file dialog is closed on click-that-selects-a-file, you'll see the Click reaching the main window. Similar thing for closed Tk non-main toplevel windows by double-clicking on system menu icon: if another tk window happens to be under the click, it receives an event.

  Tk assumes that if a mouse button was released and is now pressed, then it must generate an event (Tk_UpdatePointer). This patch adds a special flag for Tk_UpdatePointer to take exception from this assumption. This modification proven to be useful for many other things during 4 years I maintain it for my projects.

  There is another obscure manifestation of a similar problem, related to non-client clicks (like WM_NCLBUTTONDOWN): tk really shouldn't generate ButtonDown on these events. This patch adds WM_NC* handling to the toplevel window procedure, using special flag for Tk_UpdatePointer to prevent these spurious events too, and another flag to prevent cursor shape changes for non-client areas).

  Unfortunately there are another things in this patch (separating them is not easy): support for wm attr -contexthelp (uses virtual <<Help>> event, no need to worry about event mask bits exhaustion); support for wm attr -shadow (recreates wrapper window with CS_DROPSHADOW). 

  To complicate things even more, this patch includes tkUnixRFont update for -underline and -overstrike support in Xft backed. This part can be separated :)

  I would like to see something done in this direction: while we can live without improvements, though they're discussed and accepted long ago, the bugs addressed by this patch are really annoying. E.g. a user does Menu->File->Open, and his file-selecting click goes directly to toolbar->New file :(
  Should I simply commit this whole thing myself? If it's unacceptable, can anyone provide the directions for refactoring it? Maybe I should wait 4 more years..


tkt_uuid: 3536507fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 81. Portability
priority: 2
foundin: None
resolution: Fixed
title: clientData field in Tk_OptionSpec should be "const void *"
comment:
  The clientData field of Tk_OptionSpec always points to a nonmodifiable location, but because
  the type is ClientData (= void *) any constant pointer needs to be casted first.

  Suggestion: change this to "const void *", and a lot of type casts can be
  eliminated.


tkt_uuid: 220821ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 7 High
foundin: final: 8.1.1
resolution: Fixed
title: wish crashes with a Segmentation Fault
comment:
  OriginalBugID: 2227 Bug
  Version: 8.1.1
  SubmitDate: '1999-06-15'
  LastModified: '2000-02-02'
  Severity: CRIT
  Status: Assigned
  Submitter: techsupp
  ChangedBy: ericm
  OS: Linux
  OSVersion: 2.2.9
  Machine: Other


  ReproducibleScript:
  Start the Script below and repeatedly choose random letters from the
      menu.
      sometimes there may be an error, sometimes it even crashes. reproducible
      using tcl/tk 8.0.4 on linux, using tcl/tk 8.1.1 on linx and using 
      tcl/tk 8.0.2 on solaris
      
      proc trace_var {name1 name2 op} {
          global var
          puts "$var"
          set var TEXT
          draw_menu
      }
      proc draw_menu {} {
          destroy .m
          tk_optionMenu .m var A B C D E F G H
          pack .m
      }
      button .b -text "quit" -command "exit"
      pack .b
      
      set var TEXT
      trace variable var w trace_var
      
      draw_menu

  ObservedBehavior:
  > gdb wish8.1
      GDB is free software and you are welcome to distribute copies of it
       under certain conditions; type "show copying" to see the conditions.
      There is absolutely no warranty for GDB; type "show warranty" for
      details.
      GDB 4.16 (i486-unknown-linux --target i486-linux), 
      Copyright 1996 Free Software Foundation, Inc...
      (gdb) run seg-broken.tcl
      Starting program: /usr/local/bin/wish8.1 seg-broken.tcl
      
      [ many lines containing only  "A" deleted]
      
      Program received signal SIGSEGV, Segmentation fault.
      0x40079443 in TkInvokeMenu (interp=0x804a018, menuPtr=0x80cac00,
      index=0)
          at ./../generic/tkMenu.c:1112
      1112            Tcl_IncrRefCount(commandPtr);
      (gdb) print commandPtr
      $1 = (Tcl_Obj *) 0x1
      (gdb) bt
      #0  0x40079443 in TkInvokeMenu (interp=0x804a018, menuPtr=0x80cac00,
      index=0)
          at ./../generic/tkMenu.c:1112
      #1  0x40078d62 in MenuWidgetObjCmd (clientData=0x80cac00,
      interp=0x804a018, objc=3, 
          objv=0x804ac9c) at ./../generic/tkMenu.c:936
      #2  0x40135954 in TclExecuteByteCode (interp=0x804a018,
      codePtr=0x80af7c8)
          at ./../generic/tclExecute.c:843
      #3  0x40111aff in Tcl_EvalObjEx (interp=0x804a018, objPtr=0x80ac790,
      flags=0)
          at ./../generic/tclBasic.c:2698
      #4  0x40167a35 in Tcl_UplevelObjCmd (dummy=0x0, interp=0x804a018,
      objc=1, objv=0x804ac98)
          at ./../generic/tclProc.c:603
      #5  0x40135954 in TclExecuteByteCode (interp=0x804a018,
      codePtr=0x80c25c0)
          at ./../generic/tclExecute.c:843
      #6  0x40111aff in Tcl_EvalObjEx (interp=0x804a018, objPtr=0x80889d8,
      flags=0)
          at ./../generic/tclBasic.c:2698
      #7  0x4016814b in TclObjInterpProc (clientData=0x809a570,
      interp=0x804a018, objc=3, 
          objv=0xbfffecec) at ./../generic/tclProc.c:995
      #8  0x4015ef0d in EvalObjv (interp=0x804a018, objc=3, objv=0xbfffecec, 
          command=0xbffff05c "\n   tkMenuInvoke .m.menu 1\n", length=27,
      flags=0)
          at ./../generic/tclParse.c:929
      #9  0x4015f804 in Tcl_EvalEx (interp=0x804a018, 
          script=0xbffff05c "\n   tkMenuInvoke .m.menu 1\n", numBytes=27,
      flags=0)
          at ./../generic/tclParse.c:1390
      #10 0x4015fab1 in Tcl_Eval (interp=0x804a018, 
          string=0xbffff05c "\n   tkMenuInvoke .m.menu 1\n") at
      ./../generic/tclParse.c:1497
      #11 0x401137c9 in Tcl_GlobalEval (interp=0x804a018, 
          command=0xbffff05c "\n   tkMenuInvoke .m.menu 1\n") at
      ./../generic/tclBasic.c:4114
      #12 0x40022277 in Tk_BindEvent (bindingTable=0x806da90,
      eventPtr=0x80cbcb8, 
          tkwin=0x80a93b8, numObjects=0, objectPtr=0xbffff1ac) at
      ./../generic/tkBind.c:1782
      #13 0x40028edd in TkBindEventProc (winPtr=0x80a93b8,
      eventPtr=0x80cbcb8)
          at ./../generic/tkCmds.c:245
      #14 0x40031098 in Tk_HandleEvent (eventPtr=0x80cbcb8) at
      ./../generic/tkEvent.c:709
      #15 0x400315fc in WindowEventProc (evPtr=0x80cbcb0, flags=-3)
          at ./../generic/tkEvent.c:1044
      #16 0x4015c21a in Tcl_ServiceEvent (flags=-3) at
      ./../generic/tclNotify.c:573
      #17 0x4015c505 in Tcl_DoOneEvent (flags=-3) at
      ./../generic/tclNotify.c:812
      #18 0x400316ba in Tk_MainLoop () at ./../generic/tkEvent.c:1102
      #19 0x40041704 in Tk_MainEx (argc=1, argv=0xbffff448, 
          appInitProc=0x8048808 <Tcl_AppInit>, interp=0x804a018) at
      ./../generic/tkMain.c:277
      #20 0x80487f6 in main (argc=2, argv=0xbffff444) at ./tkAppInit.c:54
      #21 0x804874e in ___crt_dummy__ ()

  DesiredBehavior:
  may be an error, but absolutely no crash!
      
      N.B. Workaround: in proc trace_var, replace "draw_menu" by "after idle
      draw_menu" and there is no error.



  Verified in 8.3b2.

  - eric
   
  -- 02/02/2000 ericm


tkt_uuid: 2886983fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: None
resolution: Works For Me
title: -indicatoron no effect on menu radiobuttons
comment:
  If a menu is created with multiple radiobutton entries, using "-indicatoron 1" on one of the entries has no effect.  The value of the designated variable overrides the option.  If the designated variable is unset, the flag still has no effect.

  Example:

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

  The menu that appears has no menu entries selected.

  Example 2:

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

  the menu that appears has "Reject" selected despite the use of the -indicatoron flag.

  Version 8.5.5 on Ubuntu Hardy.


tkt_uuid: 220699ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 30. Color Names
priority: 2
foundin: obsolete: 8.3
resolution: Fixed
title: "winfo rgb" gives different results between Unix and Windows
comment:
  OriginalBugID: 4282 Bug
  Version: 8.3
  SubmitDate: '2000-03-01'
  LastModified: '2000-03-02'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All Windows
  FixedDate: '2000-03-02'
  FixedInVersion: 8.3.1


  Name: Greg Couch



  Comments:

  We're actually using 8.0.5, but xlib/xcolors.c is the same in 8.3.0.



  ReproducibleScript:

  Give the tcl command "winfo rgb . red" in wish.



  ObservedBehavior:

  On Windows you get "65280 0 0".



  DesiredBehavior:

  On Unix, you get back "65535 0 0".



  Patch:

  *** xcolors.c   2000/03/02 00:50:17     1.1

  --- xcolors.c   2000/03/02 00:59:00

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

  *** 854,862 ****

        if (l > u) {

          return 0;

        }

  !     colorPtr->red = xColors[i].red << 8;

  !     colorPtr->green = xColors[i].green << 8;

  !     colorPtr->blue = xColors[i].blue << 8;

        return 1;

    }

    



  --- 854,862 ----

        if (l > u) {

          return 0;

        }

  !     colorPtr->red = (xColors[i].red << 8) | xColors[i].red; 

  !     colorPtr->green = (xColors[i].green << 8) | xColors[i].green;

  !     colorPtr->blue = (xColors[i].blue << 8) | xColors[i].blue;

        return 1;

    }



  PatchFiles:

  xcolors.c





  Applying this patch had no effect on the end result, although

  it seems straightforward.  Also a problem is XParseColor in the

  same file, that will cause the following bad result:

      winfo rgb . #ff0000

  =>  65280 0 0 

  -- 03/02/2000 hobbs

  Needed similar patch in XParseColor in xcolors.c and also:



  ===================================================================

  RCS file: RCS/tkWinColor.c,v

  retrieving revision 1.1

  diff -c -r1.1 tkWinColor.c

  *** tkWinColor.c2000/03/02 19:06:191.1

  --- tkWinColor.c2000/03/02 19:13:36

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

  *** 373,381 ****

    

    if ((index >= cmap->size) || (newPixel != closePixel)) {

        if (cmap->size == sizePalette) {

  ! color->red = closeEntry.peRed << 8;

  ! color->green = closeEntry.peGreen << 8;

  ! color->blue = closeEntry.peBlue << 8;

    entry = closeEntry;

    if (index >= cmap->size) {

        OutputDebugString("XAllocColor: Colormap is bigger than we thought");

  --- 373,381 ----

    

    if ((index >= cmap->size) || (newPixel != closePixel)) {

        if (cmap->size == sizePalette) {

  ! color->red = (closeEntry.peRed << 8) | closeEntry.peRed;

  ! color->green = (closeEntry.peGreen << 8) | closeEntry.peGreen;

  ! color->blue = (closeEntry.peBlue << 8) | closeEntry.peBlue;

    entry = closeEntry;

    if (index >= cmap->size) {

        OutputDebugString("XAllocColor: Colormap is bigger than we thought");

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

  *** 404,412 ****

    

    color->pixel = GetNearestColor(dc,

    RGB(entry.peRed, entry.peGreen, entry.peBlue));

  ! color->red = (GetRValue(color->pixel) << 8);

  ! color->green = (GetGValue(color->pixel) << 8);

  ! color->blue = (GetBValue(color->pixel) << 8);

        }

    

        ReleaseDC(NULL, dc);

  --- 404,412 ----

    

    color->pixel = GetNearestColor(dc,

    RGB(entry.peRed, entry.peGreen, entry.peBlue));

  ! color->red = (GetRValue(color->pixel) << 8) | GetRValue(color->pixel);

  ! color->green = (GetGValue(color->pixel) << 8) | GetGValue(color->pixel);

  ! color->blue = (GetBValue(color->pixel) << 8) | GetBValue(color->pixel);

        }

    

        ReleaseDC(NULL, dc);



  Patched for 8.3.1. 

  -- 03/02/2000 hobbs


tkt_uuid: 1090382fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 7 High
foundin: obsolete: 8.5.1
resolution: None
title: possible tk-crash for font-problems
comment:
  File: tk/unix/tkUnixRFont.c

  Function GetFont() calls 
     XftFontOpenPattern(...), which under some circumstances
       *can* return NULL (I'm not sure if this can happen also
       under sane conditions, or only on misconfigured systems)
  GetFont passes on that pointer unchecked and unused.

  Function InitFont()  (same file) calls GetFont(), doesn't
     check for NULL and dereferences the pointer.
  This is where the crash happens.

  Btw., function Tk_MeasureChars() also calls GetFont()
  and passes its result directly to XftTextExtents32().
  Whether the latter deals correctly with NULL-pointers
  should be checked.

  In Tk_DrawChars() the return-value of GetFont() is 
  correctly checked for NULL.


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

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

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

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

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

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


tkt_uuid: 220896ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 33. Generic Dialog Support
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Invalid
title: focus shifts to wrong window after using tk_ built in dialog
comment:
  OriginalBugID: 4254 Bug
  Version: 8.3
  SubmitDate: '2000-02-28'
  LastModified: '2000-03-01'
  Severity: MED
  Status: UnAssn
  Submitter: angie
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion:  4.0sp5


  Tk 8.3.0 Bug

  ReproducibleScript:
  # focuslostbug.tcl
  wm title . "New focus"
  toplevel .t
  wm title .t "Original focus"
  update
  button .t.b -text "Press me!" -command focusbug
  pack .t.b 
  focus .t
  proc focusbug {} {
      tk_messageBox  -icon    question  -type    yesno  -default no  -message "Please press a button!  Notice how focus shifts"  -title  "Focus bug"
  }

  ObservedBehavior:
  When using tk_messageBox, or similar dialogs (on WinNT at least), the focus is not reset correctly when the dialog is dismissed.  This happens even though the dialog tries to do 'set oldFocus [focus] .... catch {focus $oldFocus}' internally.

  The script attached demonstrates this problem.  There are two windows, with the focus on one containing a button.  Pressing the button brings up a simple dialog, but when that dialog is dismissed the focus is now on the window without the button (the root '.' window).

  DesiredBehavior:
  Focus should remain where it was before.

  Patch:
  Using 'focus -force' can solve the problem, but I don't think it's a good solution (at least the focus man page suggests not to use -force).

  Comments:
      Tk 8.2.3 and 8.3.0 show the bug on WinNT.

  Posted To comp.lang.tcl: Posted Successfully


tkt_uuid: 605277ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
foundin: obsolete: 8.4.0
resolution: Fixed
title: ctrl-v paste doesn't work on Linux
comment:
  On Linux, I cannot use ctrl-V to paste text into a text widget 
  that I copied using ctrl-C or ctrl-X.  It works fine on Win32.

  Ctrl-C works. Ctrl-X works. Ctrl-V doesn't work. 

  This problem (on Linux) was there in 8.3.3 as well;
  I upgraded to 8.4b2 ... problem still present.

  For grins, here is the test script I used:

  #! /usr/bin/wish -f 

  global GotSelection 
  set GotSelection 0 

  frame .fr -width 10c -height 5c ;#main window 
  wm title . "Simple Text Editor V 0" 
  pack .fr 

  #configure menubar on top 
  frame .menubar -relief raised -bd 2 
  pack .menubar -in .fr -fill x 
  frame .edf 

  #put a text widget with scroll bars 

  text .ed -width 80 -height 20 -bg grey \ 
  -yscrollcommand ".ys set" 

  scrollbar .ys -command ".ed yview" 
  pack .ed .ys -in .edf -side left -fill y 

  pack .edf -in .fr -after .menubar -fill x 


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

  The following Wish 8.4.4 script

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

  displays a button with only "ome te" visible.


tkt_uuid: 3205153fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 6
foundin: None
resolution: None
title: Tk does not handle input-manager input on Mac OS X
comment:
  OS X allows the user to enter accented and CJK characters through system-provided input methods, similarly to IME on Windows and XIM on X11.  While the latter two are supported in Tk, the former is not.

  Currently on the Carbon Tk implementation there is limited support for entering accented characters, however the "working" text (usually an underlined form of the accent component itself) is not shown.  The Cocoa version does not even support this, and neither supports CJK entry at all.


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

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

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

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

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

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

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

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

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

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


tkt_uuid: 1639318fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 8
foundin: obsolete: 8.4.14
resolution: Invalid
title: tk 8.4.14 - error in TCLLIBPATH
comment:
  I am using Tcl-Tk 8.4.14 and Tix 8.4.2.

  I call "wish" with a program which requires the package Tix. I set TCLLIBPATH so that "wish" can find Tix.

  If I put a relative path to Tix in TCLLIBPATH and execute "wish" in the correct directory everything is ok. 

  But if I put an abolute path to Tix in TCLLIBPATH, "wish" cannot find Tix except if TCLLIBPATH ends with a "/".

      setenv TCLLIBPATH relative/path/to/Tix   -> ok
      setenv TCLLIBPATH /absolute/path/to/Tix  -> cannot find Tix
      setenv TCLLIBPATH /absolute/path/to/Tix/ -> ok

  Since usually variable does not end with "/", it took me quite a long time before I find a solution. It would be good to correct the code so that TCLLIBPATH can end without "/".

  Marie Vidal
  marie.vidal@inria.fr


tkt_uuid: 2952745fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 23. Option Parsing
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: Crash in menu.test on Win32
comment:
  Running the standard Tk test suite on HEAD, using VC++ 6.0 or mingw (either
  debug or release), I am experiencing a crash. On Linux, everything works
  fine, but not on Windows (XP). I managed to generate the following stack
  trace, pointing to tkConfig.c, line 1629. The visual studio debugger indicates
  that specPtr here has the value 0xcdcdef00, while optionPtr points to
  0x00d25a4c, so it looks like specPtr is used after it is freed somewhere.

  Is anyone aware of recent changes which might have causes this?
  Stack trace:
  ===========================================
  Tk_FreeConfigOptions(char * 0x01a44f70, Tk_OptionTable_ * 0x00d2edd8, Tk_Window_ * 0x01a44170) line 1629 + 3 bytes
  DestroyMenuInstance(TkMenu * 0x01a44f70) line 1237 + 27 bytes
  TkDestroyMenu(TkMenu * 0x01a44f70) line 1318 + 9 bytes
  TkMenuEventProc(void * 0x01a44f70, _XEvent * 0x0012e534) line 764 + 9 bytes
  Tk_HandleEvent(_XEvent * 0x0012e534) line 1344 + 17 bytes
  Tk_DestroyWindow(Tk_Window_ * 0x01a44170) line 1415 + 9 bytes
  Tk_DestroyWindow(Tk_Window_ * 0x018fd9d8) line 1356 + 9 bytes
  FrameCmdDeletedProc(void * 0x01fa0d78) line 1730 + 9 bytes
  Tcl_DeleteCommandFromToken(Tcl_Interp * 0x01fd0c60, Tcl_Command_ * 0x01fa0cf8) line 2980 + 13 bytes
  TclTeardownNamespace(Namespace * 0x01ffc5c8) line 1062 + 13 bytes
  DeleteInterpProc(Tcl_Interp * 0x01fd0c60) line 1390 + 12 bytes
  Tcl_EventuallyFree(void * 0x01fd0c60, void (char *)* 0x0058fb11 DeleteInterpProc(Tcl_Interp *)) line 299 + 7 bytes
  Tcl_DeleteInterp(Tcl_Interp * 0x01fd0c60) line 1280 + 14 bytes
  SlaveObjCmdDeleteProc(void * 0x01fd0c60) line 2582 + 12 bytes
  Tcl_DeleteCommandFromToken(Tcl_Interp * 0x00d058a8, Tcl_Command_ * 0x018ebac0) line 2980 + 13 bytes
  Tcl_InterpObjCmd(void * 0x00000000, Tcl_Interp * 0x00d058a8, int 3, Tcl_Obj * const * 0x00df0bbc) line 797 + 25 bytes
  NRRunObjProc(void * * 0x01a844bc, Tcl_Interp * 0x00d058a8, int 0) line 4348 + 19 bytes
  TclNRRunCallbacks(Tcl_Interp * 0x00d058a8, int 0, TEOV_callback * 0x02049290, int 1) line 4295 + 18 bytes
  TclExecuteByteCode(Tcl_Interp * 0x00d058a8, ByteCode * 0x019548a0) line 2803 + 22 bytes
  NRCallTEBC(void * * 0x016f139c, Tcl_Interp * 0x00d058a8, int 0) line 4371 + 16 bytes
  TclNRRunCallbacks(Tcl_Interp * 0x00d058a8, int 0, TEOV_callback * 0x00000000, int 0) line 4295 + 18 bytes
  Tcl_EvalObjv(Tcl_Interp * 0x00d058a8, int 1, Tcl_Obj * const * 0x00df0280, int 2097152) line 4067 + 19 bytes
  TclEvalEx(Tcl_Interp * 0x00d058a8, const char * 0x01581c90, int 783, int 0, int 22, int * 0x00000000, const char * 0x01581c90) line 5237 + 22 bytes
  Tcl_EvalEx(Tcl_Interp * 0x00d058a8, const char * 0x01581c90, int 783, int 0) line 4893 + 29 bytes
  Tcl_FSEvalFileEx(Tcl_Interp * 0x00d058a8, Tcl_Obj * 0x00d0b7e0, const char * 0x00000000) line 1746 + 19 bytes
  Tk_MainEx(int -1, char * * 0x00bc15c8, int (Tcl_Interp *)* 0x00401005 _Tcl_AppInit, Tcl_Interp * 0x00d058a8) line 270 + 26 bytes
  WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00152331, int 10) line 135 + 26 bytes
  WinMainCRTStartup() line 330 + 54 bytes
  KERNEL32! 7c817077()


tkt_uuid: 578238ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Accepted
title: Additions to ::tk::unsup::MacWindowStyle
comment:
  Adds noActivates and noUpdates to
  ::tk::unsupported::MacWindowStyle

  It was possible to get these values while querying the
  style of a window, but not to set them.

  Also, tool tips work really well with "help noActivates"


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

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

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


tkt_uuid: 1622189fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 67. Unix Window Operations
priority: 8
foundin: obsolete: 8.4.4
resolution: None
title: XIM does not work with ATOK12 on Solaris8
comment:
  I use ATOK12 on Solaris for converting Japanese character.But it does not work 
  on tcl/tk 8.4.4 and 8.4.13.

  When I convert Japanese character to KANJI on a text area, input server(ATOK12) 
  makes an auxiliary area(an auxiliary window) for selecting from some KANJI. But 
  nothing can be input on the text area after selecting a KANJI .

  When ATOK12 makes an auxiliary-window, tck/tk receives a FocusOut event.
  After selecting a KANJI on the auxiliary-window, tck/tk receives A KeyPress 
  event with a KeyCode of zero and then receives a FocusIn event.

  In this case I thought event order should be a FocusOut event, a FocusIn event and then 
  a KeyPress event according to Xlib specifications. So I asked Sun Microsystems 
  which order is correct.

  (A) a FocusOut event -> a FocusIn event -> KeyPress event with a KeyCode of zero 
  (B) a FocusOut event -> a KeyPress event with a KeyCode of zero -> FocusIn event 

  Their answer was "Both are OK.". This means Tcl/tk could have same problem not only 
  ATOK12 but also other input servers.


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

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

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

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

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

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

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

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

  And this is working fine for me with:

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

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

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

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

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

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

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

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


tkt_uuid: 3576114fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: text widget crashes on long lines if -wrap none is set
comment:
  With -wrap none, a sufficiently long line crashes the session.
  Running OpenSuse 11.4
  Crash occurs with tcl/tk 8.5.9 and 8.6b2
  Crash occurs with several different window managers

  Following program exhibits the crash:

  package require Tk
  set log_file /home/ian/tcl/crash_log

  proc main {} {
     text .t -width 80 -height 30 -bg white -font {arial -12} -wrap none
     pack .t -fill both -expand 1
     
     for {set i 0} {$i < 10000} {incr i} {
        update idletasks
        .t insert end "A"
        set fd [open $::log_file w]
        puts $fd $i
        close $fd
     }
  }
  main

  Note that the log file records how many characters were added
  before the crash. Experimenting with different font sizes shows
  that the crash occurs when the line exceeds about 8050 pixels.

  This is slightly similar to bug 624732 - but that is reported as fixed...


tkt_uuid: 220291ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 1 Zero
foundin: obsolete: 8.3
resolution: Invalid
title: text widget index current returned value bug
comment:
  OriginalBugID: 4643 Bug
  Version: 8.3
  SubmitDate: '2000-03-28'
  LastModified: '2000-03-28'
  Severity: SER
  Status: Closed
  Submitter: techsupp
  ChangedBy: ericm
  OS: Other
  OSVersion: OpenBSD 2.6
  Machine: Intel Pentium II (Klamath) (
  ClosedDate: '2000-03-28'


  Name:
  George P. Staplin

  Extensions:
  Img 1.2.3

  ReproducibleScript:
  #!/usr/local/bin/wish8.3
  text .test
  pack .test
  bind .test <KeyPress> {puts [.test index current]}

  ObservedBehavior:
  When the Enter/Return key is held down it randomly outputs the same value, despite the fact that the text widget index is different.

  $ ./tk_bug.tcl
  1.0
  2.0
  3.0
  4.0
  5.0
  6.0
  7.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  8.0
  9.0
  10.0
  11.0
  12.0
  13.0
  14.0
  15.0
  16.0
  17.0
  18.0
  19.0
  20.0
  21.0
  22.0
  23.0
  24.0
  25.0
  26.0
  27.0
  28.0
  29.0
  30.0
  ^C
  $

  This is the log when set tcl_traceExec 2 is enabled, which shows that 5 repeats:
  Calling proc tkScreenChanged
  2: (8) invoking string
  2: (33) invoking string
  2: (60) invoking uplevel
  2: (67) invoking global
  2: (74) invoking global
  2: (83) invoking info
  2: (97) invoking return
  Calling proc tkTextButton1
  2: (4) invoking global
  2: (44) invoking tkTextClosestGap
  Calling proc tkTextClosestGap
  3: (14) invoking .test
  3: (25) invoking .test
  3: (38) invoking string
  3: (62) invoking lindex
  3: (71) invoking lindex
  3: (83) invoking return
  2: (46) invoking .test
  2: (59) invoking .test
  2: (72) invoking .test
  2: (76) invoking string
  2: (85) invoking focus
  Calling proc tkTextSelectTo
  2: (6) invoking global
  2: (17) invoking tkTextClosestGap
  Calling proc tkTextClosestGap
  3: (14) invoking .test
  3: (25) invoking .test
  3: (38) invoking string
  3: (62) invoking lindex
  3: (71) invoking lindex
  3: (83) invoking return
  2: (33) invoking .test
  2: (68) invoking .test
  2: (83) invoking .test
  2: (131) invoking switch
  3: (12) invoking .test
  2: (159) invoking string
  Calling proc tkCancelRepeat
  1.0
  2: (4) invoking global
  2: (16) invoking after
  Calling proc tkTextInsert
  2.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  3.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  4.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  5.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  6.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  7.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  8.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  9.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  10.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  11.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  12.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  13.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  14.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  15.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  16.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert
  17.0
  2: (8) invoking string
  2: (31) invoking .test
  2: (35) invoking string
  2: (64) invoking .test
  2: (122) invoking .test
  2: (131) invoking .test
  Calling proc tkTextInsert

  DesiredBehavior:
  I expect the returned value from index current to be accurate and consistent.



  From the text widget manual entry:

         Two marks have  special  significance.   First,  the  mark
         insert   is  associated  with  the  insertion  cursor,  as
         described under THE INSERTION CURSOR below.   Second,  the
         mark  current  is associated with the character closest to
         the mouse and is adjusted automatically to track the mouse
         position  and  any  changes to the text in the widget (one
         exception:  current is not updated in  response  to  mouse
         motions  if  a  mouse  button is down;  the update will be
         deferred until all  mouse  buttons  have  been  released).
         Neither of these special marks may be deleted.

  Note that the "current" mark indicates the character closest to the mouse
  pointer; *not*, as you seem to expect, the character at the insertion
  cursor.  To retrieve that value, you should use ".test index insert".

  You can verify that current gives you the character closest to the mouse
  by moving the mouse around in between keypresses with this example:

  pack [text .test]
  bind .test <KeyPress> {puts "[.test index current]; [.test index insert]"}

  - eric

   
  -- 03/28/2000 ericm


tkt_uuid: 2062394fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 49. [grid]
priority: 5 Medium
foundin: obsolete: 8.5.4
resolution: Invalid
title: Incompatible change in grid command
comment:
  Tk8.5 introduces a new subcommand to grid called 
  "anchor". This subcommand controls the placing of
  grids which are smaller than its containing widget.
  Unfortunately the default behaviour is set to
  "nw" while in Tk8.4 (where you couldn't specify
  the anchor) it was "center".

  This leads to some broken layouts, like 
  iwidgets disjointlistbox with "-buttonplacement center".

  A short Tk-only example for demonstration:

  <tcl>
  frame .f -background blue
  button .f.b1 -text "Button 1"
  button .f.b2 -text "Button 2"

  # uncomment next line for 8.5 compatiblity
  #grid anchor .f center
  grid .f.b1
  grid .f.b2

  pack .f -fill both -expand true
  wm geometry . =200x800
  </tcl>

  Running this, you will see the buttons are in the
  center using 8.4 and in the upper left corner 
  using 8.5. For the latter the "grid anchor" line 
  is necessary to yield the same result (but isn't
  backward compatible).


tkt_uuid: 742882ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: Potential division by zero in gridded wm geometry
comment:
  % wm grid . 100 100 0 0
  % Floating point exception (core dumped)

  Stack backtrace:

  Program received signal SIGFPE, Arithmetic exception.
  0x0806d396 in GetMaxSize (wmPtr=0x81cfec0,
  maxWidthPtr=0xbffff634,
      maxHeightPtr=0xbffff630) at
  /usr/local/src/tk/unix/tkUnixWm.c:5839
  5839                tmp = wmPtr->reqGridWidth
  (gdb) where
  #0  0x0806d396 in GetMaxSize (wmPtr=0x81cfec0,
  maxWidthPtr=0xbffff634,
      maxHeightPtr=0xbffff630) at
  /usr/local/src/tk/unix/tkUnixWm.c:5839
  #1  0x0806b7d8 in UpdateSizeHints (winPtr=0x81cfdd0,
  newWidth=200,
      newHeight=200) at
  /usr/local/src/tk/unix/tkUnixWm.c:4235
  #2  0x0806b4db in UpdateGeometryInfo (clientData=0x81cfdd0)
      at /usr/local/src/tk/unix/tkUnixWm.c:4079
  #3  0x08164257 in TclServiceIdle ()
  #4  0x08153e02 in Tcl_DoOneEvent ()


  Bug present in CVS HEAD, 8.4, 8.3, and probably earlier.


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


tkt_uuid: 220950ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.4.9
resolution: Accepted
title: [$menu delete $index end] deletes the last index even if it
comment:
  OriginalBugID: 6241 Bug
  Version: 8.3.2
  SubmitDate: '2000-09-11'
  LastModified: 
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  OS: Windows 95


  Name:
  keith lea

  ReproducibleScript:
  % menu .f -tearoff 0
  .f
  % .f add command -label Index0
  % .f add command -label Index1
  % .f add command -label Index2
  % eval .f post [winfo pointerxy .f]
  % .f delete 600 end
  % eval .f post [winfo pointerxy .f]
  %

  DesiredBehavior:
  I think nothing should happen if the first index doesn't exist.


tkt_uuid: 220549ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: tk_get{Open|Save}File might fail to restore grab
comment:
  OriginalBugID: 2314 Bug
  Version: 8.1.1
  SubmitDate: '1999-07-01'
  LastModified: '1999-11-12'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  OS: HP-UX
  OSVersion: 10.20
  Machine: Other
  FixedDate: '1999-11-12'
  FixedInVersion: 8.3b1


  Name:

  Frank J. Leitner



  CVS:

  @(#) $Id: tkfbox.tcl,v 1.9 1999/04/16 01:51:27 stanton Exp $



  Comments:

  The problem is that the tcl-only version of tk_getOpenFile and

  tk_getSaveFile

  try to restore the focus and grab that existed prior to calling them. There

  is a catch around the line trying to restore the focus, but not around the

  grab command. You could simply add a catch to the two "grab $oldGrab" and

  "grab -global $oldGrab" line, or apply the above patch.



  Please note that this bug isn't restricted to 8.1(.1), it's propably

  been there since those commands were created. And it is still in the

  CVS version as of July 30.



  ReproducibleScript:

  Two different scripts giving two different error messages:

      

        pack [entry .e]

        grab .e

        after 2000 "destroy .e"; tk_getOpenFile

      

      throws

      

        bad window path name ".e"

      

      and

      

        pack [entry .e]

        grab -global .e; after 2000 "pack forget .e"; tk_getOpenFile

      

      gives

      

        grab failed: window not viewable

      

      Both errors happen when closing the tk_getOpenFile box after

      the entry widget has disappeard.



  ObservedBehavior:

  bad window path name ".e"

          while executing

      "grab $oldGrab"

          (procedure "tk_getOpenFile" line 91)

          invoked from within

      "tk_getOpenFile"

      --------8<---------------8<---------

      grab failed: window not viewable

          while executing

      "grab -global $oldGrab"

          (procedure "tk_getOpenFile" line 89)

          invoked from within

      "tk_getOpenFile"



  Patch:

  *** tkfbox.tcl.orig     Fri Apr 16 03:51:27 1999

  --- tkfbox.tcl  Wed Jun 30 16:42:53 1999

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

  *** 729,736 ****

        catch {focus $oldFocus}

        grab release $w

        wm withdraw $w

  !     if {$oldGrab != ""} {

  !       if {$grabStatus == "global"} {

              grab -global $oldGrab

          } else {

              grab $oldGrab

  --- 729,736 ----

        catch {focus $oldFocus}

        grab release $w

        wm withdraw $w

  !     if {[winfo exists $oldGrab]} {

  !       if {$grabStatus == "global" && [winfo viewable $oldGrab]} {

              grab -global $oldGrab

          } else {

              grab $oldGrab



  PatchFiles:

  library/tkfbox.tcl





  The winfo viewable belongs with the exists.  Fixed. 
  -- 11/12/1999 hobbs


tkt_uuid: 3585396fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 8
foundin: obsolete: 8.5.13
resolution: Fixed
title: winDialog.test requires user interaction
comment:
  It's reported that on Vista the tests winDialog-5.{8,9,24}
  require user interaction.  If this cannot be fixed, then
  these tests should be disabled by constraint.


tkt_uuid: 1237759fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 28. Utility Functions
priority: 5 Medium
foundin: None
resolution: Accepted
title: Bring Tk library up to 8.4 code standards
comment:
  From Patrick Fradin [patrick.fradin at synelec.fr]:

  I made next modifications joined in 2 archives :

      - Always use eq / ne to compare strings instead of
  string equal, string match, string compare, == and so
  on... I think it's simplify code readability and
  maintenance.

      - Replace some simple regsub with string map to
  improve exec performance

      - Replace some simple regexp with string match for
  the same reasons

      - Use unset -nocomplain to avoid if info exists or
  catch

      - Use trace add variable write/unset instead of old
  trace variable w/u

      - Use trace remove variable instead of old trace
  vdelete

      - Use trace info variable instead of old trace vinfo

      - use [list] to initialize empty list instead of ""
  or {} string

      - Avoid code abbreviations to clarify code and
  avoid reading errors

          ex: string len -> string length
              $w config  -> $w configure ...

      - Replace some simple eval $cmd commands with
  "compiled" if 1 $cmd
  (speedier)

      - Use foreach to parse values instead of many
  lindex (ex: clrpick.tcl)

      - Replace regexp "dummy" variable with "->" to
  improve readability

      - I remarked some catch {destroy $w}. I think it's
  useless, isn't it ?


tkt_uuid: 2108411fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: Invalid
title: checkbutton menu entry odd behavior
comment:
  # This should be the minimal repro script: 

  pack [entry .entry]; update

  menu .menuBar
  . configure -menu .menuBar

  menu .menuBar.testMenu -tearoff 0

  tk_messageBox -message \
      "ismapped = [winfo ismapped .entry]"

  .menuBar.testMenu add checkbutton -label \
      "Menu Label Here" -underline 0 \
      -indicatoron [winfo ismapped .entry] \
      -command [list doStuff]

  set index [.menuBar.testMenu index "Menu Label Here"]

  #
  # BUG 1: The -variable option has not been set,
  #        yet it has the same value as the -label 
  #        option?
  #
  tk_messageBox -message \
      "-variable = [.menuBar.testMenu entryconfigure $index -variable]"

  .menuBar add cascade -menu .menuBar.testMenu \
      -label "Menu" -underline 0

  bind . <F2> [list console show]
  bind . <F7> [list doStuff]

  wm geometry . 200x200

  proc doStuff {} {
    if {[winfo ismapped .entry]} then {
      pack forget .entry; update
    } else {
      pack .entry; update
    }

    tk_messageBox -message \
        "ismapped = [winfo ismapped .entry]"

    #
    # BUG 2: This does not seem to have any effect 
    #        on the user interface.
    #
    .menuBar.testMenu entryconfigure $::index \
        -indicatoron [winfo ismapped .entry]
  }


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

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


tkt_uuid: 3049518fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 44. Generic Fonts
priority: 5 Medium
foundin: None
resolution: None
title: Fire Event when a used font changes
comment:
  When a named font is used by a widget:
  % font create Custom -size 8
  % label .l -font Custom
  and the font is reconfigured:
  % font configure Custom -size 17
  all core widgets automatically change their size.

  If a megawidget uses a named font and does some position calculations on the font size,
  there is no way to get notified if the font size change to trigger a size change.
  In consequence, widgets look corrupted after a font size change.

  Example megawidgets are: NoteBook from BWidgets, TableList

  The demanded feature is to send an event if the size of the font changes.
  Example:
  bind .l <FontChange> reConfigure

  This would be similar to the Configure event.


tkt_uuid: 220479ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.3
resolution: Fixed
title: Problem with 2 buttons calling tk_getSaveFile
comment:
  OriginalBugID: 1676 Bug
  Version: 8.0p2
  SubmitDate: '1999-03-31'
  LastModified: '2000-02-01'
  Severity: MED
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.6
  Machine: Other
  FixedDate: '2000-02-01'
  FixedInVersion: 8.3b2


  Name:
  Eric Brunel

  ReproducibleScript:
      The code is the following:
      
      proc file1 {} {
        tk_getSaveFile -parent .wdw
      }
      proc file2 {} {
        tk_getSaveFile
      }
      toplevel .wdw
      button .wdw.btn1 -text Button1 -command {file1}
      pack .wdw.btn1 -side top
      button .wdw.btn2 -text Button2 -command {file2}
      pack .wdw.btn2 -side top
      
      Run the script with the wish interpretor without arguments, then:
      - click "Button1", go to /tmp (using the buttons), enter a dummy
      filename and press "Save";
      - click "Button2", go to another directory (like /var/tmp for example),
      enter another dummy filename and press "Save";
      - click "Button1" again
      



  ObservedBehavior:
      The dialog appears, but the "parent directory" button does not work as
      intended (the directory name is updated, but not the file list) and the
      "Save" button does not close the window...
      



  DesiredBehavior:
      Normal operation for tk_getSaveFile: the "parent directory" button must
      refresh the file list and the "Save" button must close the window and
      return the selected file.
      





      Making the dialog in proc. file2 a child of .wdw seems to solve the
      problem. But this solution may not be applicable...
      
  --
  This was fixed with other Unix dialog enhancements in 8.3b2. 
  -- 02/01/2000 hobbs


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

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

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

  Concise Code Sample:

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

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


tkt_uuid: 1678582fffffffffffffffffffffffffffffffff
type: RFE
status: Open
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: Use native curves (where available)
comment:
  A couple of weeks ago, I upgraded my TclTkAqua installation because I needed dashed lines. I did get them, but I also got some rather disturbing sideeffects...

  (At this point, please download and unpack the attachment images.tar.gz, since the text will make a lot more sense if you can also see the images.)

  1. Before the upgrade, things looked as in CG0.png: smooth lines of constant width. Things still look this way if I set tk::mac::useCGDrawing to 0 (hence the image name), but this is hardly the way forward (I suspect I'd lose the ability to draw dashed lines, for one).

  2. What shocked me is the image CG1-AAL3.png ($tk::mac::useCGDrawing==1 and $tk::mac::CGAntialiasLimit==3, i.e., the default). where several curves seem affected by extreme scurf, in some places being three times thicker than normal. This is BAD!

  3. I then tried decreasing $tk::mac::CGAntialiasLimit to 1, which brings us to CG1-AAL1.png. This is acceptable, so it is what I use, but it is not good that one has to fiddle with such platform-specific settings in order to get an acceptable picture.

  And what causes the horrible rendering in CG1-AAL3.png?

  4. Following a hunch that the problem has to do with rounding in the rendering of curves as many small line segments, I try decreasing the -splinesteps setting to 3, resulting in CG1-AAL3-SS3.png. This looks very much like CG0.png, except for the occational pixel spur, so apparently the hunch was correct: the default rendering of curves is to blame. Turning on antialiasing can hide the problem, but Tk still sends data with a lot of noise in it to the rendering software, so it hardly qualifies as a cure.

  What could be done?

  One thing that comes to mind is to let Quartz (the Mac OS X graphics engine) do the rendering of curves, instead of insisting on doing it in Tk; there is a function CGContextAddCurveToPoint which takes the same kind of data as the postscript canvas subcommand needs, so why not take advantage of that? (It would most likely be both faster and produce higher quality pictures.) Why stick to lines (and arcs)?

  Apparently because Xlib doesn't know about them, and Tk does all its drawing through the Xlib Emulation Layer. [Sigh.] There's no technical reason for Tk's emulation to be confined to what Xlib has native operations for however, so I guess this RFE boils down to:

  * Add drawing "primitives" that deal with curves (whose segments are cubic Bezier curves), and use these when drawing -smooth canvas items. Implement as now (via XDrawLines etc.) on platforms which don't natively support curves, but take advantage of such support when available. The -splinesteps parameter could be an argument to the new drawing primitives, to be used or ignored depending on whether it makes sense for the implementation in question. *

  Another thing that would be nice is if these new drawing primitives could be relieved of the Xlib restriction that all coordinates are integers. Subpixel precision is sometimes important!

  Lars Hellström


tkt_uuid: 2636558fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 40. Bitmap Images
priority: 5 Medium
foundin: None
resolution: Fixed
title: Tk_DefineBitmap and Tk_GetBitmapFromData signature problem
comment:
  The current signatures of those two functions result
  in a type cast needed for every call. In tkBitmap.c
  there are 10 such calls. The reason for this is
  that standard the bitmap data is defined as
  const unsigned char[], while the function
  requires a const char[].

  Proposed solution: change the
    const char *source
  parameter to
    const void *source.

  This is fully binary and source
  compatible, only it prevents the
  need for the type cast.


tkt_uuid: 980109ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5a2
resolution: Fixed
title: panic "Bad tag priority being toggled on" using tkChat...
comment:
  Statement apparently causing the error:

  tk::TextSetCursor .txt [tk::TextUpDownLine .txt -1]

  Stack trace:

  NTDLL! DbgBreakPoint address 0x77f7645c
  Tcl_PanicVA(const char * 0x0033de74, char * 
  0x0012e1e4) line 96 + 44 bytes
  Tcl_Panic(const char * 0x0033de74) line 133 + 13 bytes
  TkTextIndexBackChars(const TkText * 0x01b727f0, 
  const TkTextIndex * 0x0012e40c, int 1, TkTextIndex * 
  0x0012e40c, int 3) line 1841 + 16 bytes
  ForwBack(TkText * 0x01b727f0, const char * 
  0x01fd9ac7, TkTextIndex * 0x0012e40c) line 1200 + 21 
  bytes
  GetIndex(Tcl_Interp * 0x008c6e18, TkText * 
  0x01b727f0, const char * 0x01fd9ac0, TkTextIndex * 
  0x0012e40c, int * 0x0012e41c) line 902 + 20 bytes
  TkTextGetIndexFromObj(Tcl_Interp * 0x008c6e18, 
  TkText * 0x01b727f0, Tcl_Obj * 0x01fd9bb0) line 218 + 
  49 bytes
  TextWidgetObjCmd(void * 0x01b727f0, Tcl_Interp * 
  0x008c6e18, int 3, Tcl_Obj * const * 0x008c7764) line 
  1145 + 20 bytes
  TclEvalObjvInternal(Tcl_Interp * 0x008c6e18, int 3, 
  Tcl_Obj * const * 0x008c7764, const char * 
  0x00000000, int 0, int 0) line 3145 + 27 bytes
  TclExecuteByteCode(Tcl_Interp * 0x008c6e18, 
  ByteCode * 0x02331e30) line 1672 + 39 bytes
  TclCompEvalObj(Tcl_Interp * 0x008c6e18, Tcl_Obj * 
  0x00f68630) line 1011 + 13 bytes
  TclObjInterpProc(void * 0x00f69c00, Tcl_Interp * 
  0x008c6e18, int 3, Tcl_Obj * const * 0x0012f66c) line 
  1088 + 19 bytes
  TclEvalObjvInternal(Tcl_Interp * 0x008c6e18, int 3, 
  Tcl_Obj * const * 0x0012f66c, const char * 
  0x0012fbb9, int 26, int 0) line 3145 + 27 bytes
  Tcl_EvalEx(Tcl_Interp * 0x008c6e18, const char * 
  0x0012fbb9, int 26, int 0) line 3644 + 39 bytes
  TclSubstTokens(Tcl_Interp * 0x008c6e18, Tcl_Token * 
  0x0012f7fc, int 1, int * 0x00000000) line 2004 + 31 bytes
  Tcl_EvalEx(Tcl_Interp * 0x008c6e18, const char * 
  0x0012fb9c, int 57, int 0) line 3568 + 31 bytes
  Tcl_Eval(Tcl_Interp * 0x008c6e18, const char * 
  0x0012fb9c) line 3759 + 17 bytes
  Tcl_GlobalEval(Tcl_Interp * 0x008c6e18, const char * 
  0x0012fb9c) line 4911 + 13 bytes
  Tk_BindEvent(Tk_BindingTable_ * 0x008cf048, _XEvent 
  * 0x01fda1d8, Tk_Window_ * 0x01b72ba0, int 0, void * 
  * 0x0012fca8) line 1806 + 25 bytes
  TkBindEventProc(TkWindow * 0x01b72ba0, _XEvent * 
  0x01fda1d8) line 286 + 31 bytes
  Tk_HandleEvent(_XEvent * 0x01fda1d8) line 1064 + 13 
  bytes
  WindowEventProc(Tcl_Event * 0x01fda1d0, int -3) line 
  1446 + 12 bytes
  Tcl_ServiceEvent(int -3) line 624 + 13 bytes
  Tcl_DoOneEvent(int -3) line 929 + 9 bytes
  Tk_MainLoop() line 1627 + 15 bytes
  Tk_MainEx(int 1, char * * 0x008d0060, int (Tcl_Interp *)
  * 0x004010f3 Tcl_AppInit(Tcl_Interp *), Tcl_Interp * 
  0x008c6e18) line 299
  WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 
  0x00000000, char * 0x00133750, int 1) line 129 + 37 
  bytes
  WinMainCRTStartup() line 330 + 54 bytes
  KERNEL32! GetProcessPriorityBoost + 279 bytes

  -------------------

  Code around the panic (in "generic/tkTextIndex.c" near 
  line #1841):

  if (tagPtr->elideString != NULL) {
      infoPtr->tagCnts[tagPtr->priority]
  ++;
      if (infoPtr->tagCnts[tagPtr-
  >priority] & 1) {
  infoPtr->tagPtrs[tagPtr-
  >priority] = tagPtr;
      }
      if (tagPtr->priority >= infoPtr-
  >elidePriority) {
  if (segPtr->typePtr == 
  &tkTextToggleOnType) {
      /* 
       * If it is being toggled 
  on, and it has
       * an elide string, it must 
  actually be the
       * current highest 
  priority tag, so this
       * check is redundant:
       */
      if (tagPtr->priority != 
  infoPtr->elidePriority) {
  Tcl_Panic("Bad 
  tag priority being toggled on");
      }

      
      /* 
       * Find previous elide 
  tag, if any (if not
       * then elide will be zero, 
  of course).
       */
      elide = 0;
      while (--infoPtr-
  >elidePriority > 0) {
  if (infoPtr-
  >tagCnts[infoPtr->elidePriority] & 1) {


tkt_uuid: 689099ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Pane increases size badly
comment:
  The panedwindow does not compute the sizes
  correctly when increasing the size.
  It subtracts the borderwidth wrongly in a
  way that gets obvious when increasing this:

  panedwindow .p -bd 10
  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

  Attached is a fix and a test case.

  If a maintainer says ok I can commit
  this before 8.4.2.


tkt_uuid: 2954673fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Wont Fix
title: Canvas line stipple ignored in Tk Cocoa
comment:
  Canvas line stipple gray25 is ignored by Tk Cocoa 8.6 source code from Jan 8, 2010.  The line appears solid as if no stipple was specified.  The line stipple also has no effect in Tk Aqua 8.5.8.  It works correctly in Tk 8.5.8 with X windows on the Mac.

  Below is a Wish script that demonstrates the problem.  The upper line of the two lines shown should show only a checkerboard of pixels while the lower line should be solid.  In Tk Cocoa 8.6 and Tk Aqua 8.5.8 both are solid.

  canvas .c
  pack .c
  .c create line 0 50 100 50 -stipple gray25 -width 5
  .c create line 0 60 100 60 -width 5


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

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

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

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

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

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

  I am using gcc 

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


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

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

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

  I believe this is a bug.


tkt_uuid: 411781ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: None
title: \t causes trouble with justified text
comment:
  If \t is included in text that is center or right 
  justified (using tag configure -justify) the tab 
  characters appear on the screen as small rectangles - 
  of the style often used for unavailable characters.

  This occurs with Tk8.3 on windows (possibly others, I 
  don't know)

  This looks excessively yucky!

  I guess there are possible situations in which \t makes 
  no sense in justified text. In these cases I would 
  suggest the best course is not to write anything on the 
  screen for the \t character, and to raise an error 
  which could be processed or ignored using catch


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

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


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


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

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


tkt_uuid: 1192095fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.5a3
resolution: None
title: Toplevel menus return incorrect active index
comment:
  Tk: v8.5a3 HEAD, v8.4.9 HEAD
  OS: WinXPsp2, Debian Linux-woody-testing

  When the attached script is run some unusual 
  behaviour is observable.

  First on Windows with 8.5 & 8.4
  Mouse over the menus without opening them - no output
  Now open the 'help' menu, active index is correct (if 
  zero based like cascade menus) but returned label 
  says you are in the 'edit' menu.
  Moving to the 'edit' menu will produce similar 
  results.
  Moving to the 'file' menu will cause a crash.
  Also noticable is that the binding is called twice.

  Moving onto Linux and 8.5 and 8.4
  Everything works as expected.
  Mousing over menu without opening them triggers 
  binding.
  Labels are returned correctly.
  Indices are returned and are one based unlike cascade 
  menus which are zero based.
  Binding is also called twice.


tkt_uuid: 219925ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 07. [entry]
priority: 1 Zero
foundin: obsolete: 8.0.4
resolution: Duplicate
title: Cut/copy/paste in entry window uses global 'data' variable
comment:
  OriginalBugID: 1337 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '1999-04-16'
  Severity: MED
  Status: Closed
  Submitter: pat
  ChangedBy: stanton
  RelatedBugIDs: 1475
  OS: Windows 95
  OSVersion: OEM Service Release 3
  Machine: X86
  ClosedDate: '1999-04-16'


  Name:

  Kevin B. Kenny



  CVS:

  # RCS: @(#) $Id: entry.tcl,v 1.5 1998/09/14 18:23:23 stanton Exp $



  Extensions:

  None relevant to this test



  CustomShell:

  No modifications relevant to this test.



  ReproducibleScript:

      # The cut/copy/paste mechanism on entry windows uses an undocumented

      # global variable named 'data'.  If the user happens to use this name

      # for a scalar, the cut/copy/paste mechanism corrupts the content

      # of the user's variable.  If the variable is an array, an attempt

      # to cut or copy fails silently.  

      

      package require Tk

      global data

      set data(x) y

      grid [entry .e]

      grid [entry .f]

      .e insert insert abcdef

      .e selection range 1 4

      focus .e

      event generate .e <<Copy>>

      puts $errorInfo

      

      







  ObservedBehavior:

      There are two bugs here; the error occurs in response to the generated

      event, and the error is not reported.  The stack trace *is* left

      in $::errorInfo:

      

      can't set "data": variable is array

          while executing

      "set data [string range [.e get] [.e index sel.first] [expr {[.e index

      sel.last] - 1}]]"

      

      







  DesiredBehavior:

      I'd expect the string 'bcde' on the CLIPBOARD selection

      







  Patch:

  *** F:/Program Files/Tcl8.0.4/lib/tk8.0/entry.tclMon Sep 14 11:23:24 1998

  --- E:/Program Files/Tcl8.0.4/lib/tk8.0/entry.tclSat Feb 27 23:09:40 1999

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

  *** 32,69 ****

    # The code below creates the default class bindings for entries.

    #-------------------------------------------------------------------------

    bind Entry <<Cut>> {

  !     if {![catch {set data [string range [%W get] [%W index sel.first]\

  !     [expr {[%W index sel.last] - 1}]]}]} {

  ! clipboard clear -displayof %W

  ! clipboard append -displayof %W $data

  ! %W delete sel.first sel.last

  !     }

    }

    bind Entry <<Copy>> {

  !     if {![catch {set data [string range [%W get] [%W index sel.first]\

  !     [expr {[%W index sel.last] - 1}]]}]} {

  ! clipboard clear -displayof %W

  ! clipboard append -displayof %W $data

  !     }

    }

    bind Entry <<Paste>> {

  !     global tcl_platform

  !     catch {

  ! if {"$tcl_platform(platform)" != "unix"} {

  !     catch {

  ! %W delete sel.first sel.last

  !     }

  ! }

  ! %W insert insert [selection get -displayof %W -selection CLIPBOARD]

  ! tkEntrySeeInsert %W

  !     }

    }

    bind Entry <<Clear>> {

        %W delete sel.first sel.last

    }

    bind Entry <<PasteSelection>> {

        if {!$tkPriv(mouseMoved) || $tk_strictMotif} {

  ! tkEntryPaste %W %x

        }

    }

    

  --- 32,51 ----

    # The code below creates the default class bindings for entries.

    #-------------------------------------------------------------------------

    bind Entry <<Cut>> {

  !     tkEntryCut %W

    }

    bind Entry <<Copy>> {

  !     tkEntryCopy %W

    }

    bind Entry <<Paste>> {

  !     tkEntryPaste %W

    }

    bind Entry <<Clear>> {

        %W delete sel.first sel.last

    }

    bind Entry <<PasteSelection>> {

        if {!$tkPriv(mouseMoved) || $tk_strictMotif} {

  ! tkEntryPasteSelection %W %x

        }

    }

    

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

  *** 392,398 ****

  --- 374,431 ----

        update idletasks

    }

    

  + # tkEntryCut --

  + # This procedure cuts the selection text from the entry and

  + # places it on the clipboard.

  + #

  + # Arguments:

  + # w -The entry window.

  + 

  + proc tkEntryCut { w } {

  +     if {![catch {set data [string range [$w get] [$w index sel.first]\

  +     [expr {[$w index sel.last] - 1}]]}]} {

  + clipboard clear -displayof $w

  + clipboard append -displayof $w $data

  + $w delete sel.first sel.last

  +     }

  + }

  + 

  + # tkEntryCopy --

  + # This procedure copies the selected text from the entry to the

  + # clipboard.

  + #

  + # Arguments:

  + # w -The entry window

  + 

  + proc tkEntryCopy { w } {

  +     if {![catch {set data [string range [$w get] [$w index sel.first]\

  +     [expr {[$w index sel.last] - 1}]]}]} {

  + clipboard clear -displayof $w

  + clipboard append -displayof $w $data

  +     }

  + }

  + 

    # tkEntryPaste --

  + # This procedure pastes the text from the clipboard into the

  + # entry window

  + #

  + # Arguments:

  + # w -The entry window

  + 

  + proc tkEntryPaste { w } {

  +     global tcl_platform

  +     catch {

  + if {"$tcl_platform(platform)" != "unix"} {

  +     catch {

  + $w delete sel.first sel.last

  +     }

  + }

  + $w insert insert [selection get -displayof $w -selection CLIPBOARD]

  + tkEntrySeeInsert $w

  +     }

  + }

  + 

  + # tkEntryPasteSelection --

    # This procedure sets the insertion cursor to the current mouse position,

    # pastes the selection there, and sets the focus to the window.

    #

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

  *** 400,406 ****

    # w -The entry window.

    # x -X position of the mouse.

    

  ! proc tkEntryPaste {w x} {

        global tkPriv

    

        $w icursor [tkEntryClosestGap $w $x]

  --- 433,439 ----

    # w -The entry window.

    # x -X position of the mouse.

    

  ! proc tkEntryPasteSelection {w x} {

        global tkPriv

    

        $w icursor [tkEntryClosestGap $w $x]









  PatchFiles:

      entry.tcl

      









      The patch fixes only the problem of using the global 'data' array.
      I haven't yet had the chance to trace my way through 'event generate'
      to find out where the TCL_ERROR return is getting lost.  I'm not
      even sure what it's *supposed* to do; should it return as an error from
      'event generate', or should it land in 'bgerror' instead?  I'm convinced
      that having it simply disappear is not The Right Thing.  8-)
      


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

  The code:

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

  The bad behavior:

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

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


tkt_uuid: 1152376fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: TIP Implementation
resolution: Fixed
title: TIP#286: Add xposition subcommand to menus
comment:
  The menu widget has had a yposition subcommand for a
  long time, but currently there is no xposition
  subcommand. The xposition command may be needed for
  menubar type menus and in multicolumn menus.


tkt_uuid: 2190619fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 81. Portability
priority: 8
foundin: obsolete: 8.6a3
resolution: Fixed
title: Warnings due to Tk_SmoothMethod name constness change
comment:
  the constness change to the name field of Tk_SmoothMethod in
  http://fisheye.categorifiedcoder.info/browse/Tk/tk/generic/tk.h?r2=1.119&r1=1.118
  leads to the following warning:
  tk/generic/tkCanvUtil.c: In function 'TkSmoothPrintProc':
  tk/generic/tkCanvUtil.c:825: warning: return discards qualifiers from pointer target type

  either the return value of TkSmoothPrintProc() needs to be made const, and thus all functions of type Tk_OptionPrintProc, as well as that type itself; or the change above needs to be reverted; or TkSmoothPrintProc() needs to copy its return string into a temporary buffer


tkt_uuid: 917433ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 30. Color Names
priority: 9 Immediate
foundin: obsolete: 8.4.6
resolution: Fixed
title: Application initialization failed: unknown color name
comment:
  Whne trying to run amsn on linux in the console i get
  thiss error that i think has with wish to do?

  Application initialization failed: unknown color name
  "Black" 


tkt_uuid: 220867ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Out of Date
title: patch to Tk text widget to provide proper '-blockcursor' con
comment:
  OriginalBugID: 2811 RFE
  Version: 8.2
  SubmitDate: '1999-09-16'
  LastModified: '2000-04-16'
  Severity: MED
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows NT
  OSVersion: 4.0sp5
  Machine: X86


  Name:
  Vince Darley

  Comments:
  This is a completely new different patch to my previous one (which
      changed
      the behaviour of '-insertwidth' to provide a pseudo-block-cursor).  This
      patch provides a true block cursor.

  DesiredBehavior:
  Add option '-blockcursor BOOLEAN' to the text widget, which if
      true changes the insertion cursor to a flashing block whose width
      is set to the width of the current character.

  Patch:
  ftp://ftp.ucsd.edu/pub/alpha/tcl/extensions/tktext.diff

  PatchFiles:
  tkText.c
      tkText.h
      tkTextMark.c
      tk(Win|Mac|Unix)Default.h


tkt_uuid: 568278ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 35. [tk_dialog]
priority: 5 Medium
foundin: None
resolution: Accepted
title: Break tk dialog transient/master
comment:
  This patch fixes a problem where Tk dialogs can
  be mapped because a transient master (the -parent)
  is iconified/deiconified. This was a result of
  the new transient state mirroring functionality.


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


tkt_uuid: 628863ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.4.1
resolution: Rejected
title: tab incorrect with lmargin1
comment:
  in the latest 8.4.1 with the following code:

  text .text
  .text tag configure text -lmargin1 30 -font {Courier 10}
  .text insert 1.0 "a\n\tb\tc"
  .text tag add text 0.0 end
  pack .text

  the distance between a,b is not the same as
  the distance between b,c. the first tabstop seems
  to be caculated wrong, this seems to be caused
  by the -lmargin1 parameter, 

  the following diff in tkTextDisp.c seems to fix the
  problem:
  320c320
  <                           TkTextDispChunk *chunkPtr));
  ---
  >                           TkTextDispChunk *chunkPtr, int 
  tabOrigin));
  379c379
  <                           int maxX));
  ---
  >                           int maxX, int tabOrigin));
  800a801
  >     int tabOrigin;
  880a882
  >     tabOrigin = 0;
  958a961
  >           tabOrigin = x;
  1060c1063
  <               AdjustForTab(textPtr, tabArrayPtr, tabIndex, 
  tabChunkPtr);
  ---
  >               AdjustForTab(textPtr, tabArrayPtr, tabIndex, 
  tabChunkPtr, tabOrigin);
  1065c1068
  <           tabSize = SizeOfTab(textPtr, tabArrayPtr, 
  tabIndex, x, maxX);
  ---
  >           tabSize = SizeOfTab(textPtr, tabArrayPtr, 
  tabIndex, x, maxX, tabOrigin);
  1131c1134
  <       AdjustForTab(textPtr, tabArrayPtr, tabIndex, 
  tabChunkPtr);
  ---
  >       AdjustForTab(textPtr, tabArrayPtr, tabIndex, 
  tabChunkPtr, tabOrigin);
  4823c4826
  < AdjustForTab(textPtr, tabArrayPtr, index, chunkPtr)
  ---
  > AdjustForTab(textPtr, tabArrayPtr, index, chunkPtr, 
  tabOrigin)
  4834a4838
  >     int tabOrigin;
  4864c4868
  <       desired = NextTabStop(textPtr->tkfont, x, 0);
  ---
  >       desired = NextTabStop(textPtr->tkfont, x, 
  tabOrigin);
  5005c5009
  < SizeOfTab(textPtr, tabArrayPtr, index, x, maxX)
  ---
  > SizeOfTab(textPtr, tabArrayPtr, index, x, maxX, 
  tabOrigin)
  5016a5021
  >     int tabOrigin;
  5022c5027
  <       tabX = NextTabStop(textPtr->tkfont, x, 0);
  ---
  >       tabX = NextTabStop(textPtr->tkfont, x, tabOrigin);


tkt_uuid: 1708403fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.5a6
resolution: Fixed
title: Crash testing tk8.5a6-rc3
comment:
  I've downloaded, built (just said "make"), and tested the rc3 versions of tcl8.5a6 and tk8.5a6 today. Tcl was fine (the only test failures were in filesystem.test, regarding link normalisation), but Tk is does not seem fine. In particular, I got a crash running the tests. Crash log is attached (dunno if that is at all useful when it was I that made the build, though).

  I also had a problem that the it got hung on some choosedir and clrpick tests -- a Wish [bgerror] dialog pops up saying respectively:
  Error: can't access "::tk::dialog::file::__tk_choo...
  Error: bad window path name ".__tk__color"
  I've not seen any way out of these other than doing Ctrl-C in the terminal.

  [parray tcl_platform] reports:
  tcl_platform(byteOrder)   = bigEndian
  tcl_platform(machine)     = Power Macintosh
  tcl_platform(os)          = Darwin
  tcl_platform(osVersion)   = 7.9.0
  tcl_platform(platform)    = unix
  tcl_platform(pointerSize) = 4
  tcl_platform(threaded)    = 1
  tcl_platform(user)        = lars
  tcl_platform(wordSize)    = 4


  Skipping choosedir-* and clrpick-*, the output from all.tcl is:

  Tests running in interp:  /Installerare/Tcl/build/tk/Development/tktest
  Tests located in:  /Installerare/Tcl/tk8.5a6/tests
  Tests running in:  /Installerare/Tcl/build/tk/Development
  Temporary files stored in /Installerare/Tcl/build/tk/Development
  Test files sourced into current interpreter
  Skipping tests that match:  choosedir-* clrpick-*
  Running tests that match:  *
  Skipping test files that match:  l.*.test
  Only running test files that match:  *.test
  Tests began at Thu Apr 26 23:18:14 +0200 2007
  bell.test
  Bell should ring now ...
  bgerror.test
  bind.test


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

      setup
      bind .b.f <Key> "lappend x Key%K"
      bind .b.f <KeyRelease> "lappend x Release%K"
      set x {}
      event gen .b.f <Key> -keycode 0
      event gen .b.f <KeyRelease> -keycode 0
      set x

  ---- Result was:
  Keya Releasea
  ---- Result should have been (exact matching):
  Key?? Release??
  ==== bind-13.13 FAILED



  ==== bind-15.7 MatchPatterns procedure, ignoring type mismatches FAILED
  ==== Contents of test case:

      setup
      bind .b.f <Double-1> {set x 1}
      set x 0
      event gen .b.f <Button-1>
      event gen .b.f <Key-Shift_L>
      event gen .b.f <ButtonRelease-1>
      event gen .b.f <Button-1>
      event gen .b.f <ButtonRelease-1>
      set x

  ---- Result was:
  0
  ---- Result should have been (exact matching):
  1
  ==== bind-15.7 FAILED

  bitmap.test
  border.test
  button.test
  canvImg.test


  ==== canvImg-4.2 ConfiugreImage procedure FAILED
  ==== Contents of test case:

      .c delete all
      .c create image 50 100 -image foo -tags i1 -anchor nw
      update
      set x {}
      set y {}
      .c itemconfigure i1 -image foo2
      update
      list $x $y [.c bbox i1]

  ---- Result was:
  {{foo free}} {{foo2 get} {foo2 display 0 0 80 60 50 100}} {50 100 130 160}
  ---- Result should have been (exact matching):
  {{foo free}} {{foo2 get} {foo2 display 0 0 80 60 30 30}} {50 100 130 160}
  ==== canvImg-4.2 FAILED



  ==== canvImg-10.1 TranslateImage procedure FAILED
  ==== Contents of test case:

      .c delete all
      .c create image 50 100 -image foo -tags image -anchor nw
      update
      set x {}
      foo changed 2 4 6 8 30 15
      update
      set x

  ---- Result was:
  {foo display 2 4 6 8 52 104}
  ---- Result should have been (exact matching):
  {foo display 2 4 6 8 30 30}
  ==== canvImg-10.1 FAILED



  ==== canvImg-11.1 TranslateImage procedure FAILED
  ==== Contents of test case:

      .c delete all
      .c create image 50 100 -image foo -tags image -anchor nw
      update
      set x {}
      foo changed 2 4 6 8 40 50
      update
      set x

  ---- Result was:
  {foo display 0 0 40 50 50 100}
  ---- Result should have been (exact matching):
  {foo display 0 0 40 50 30 30}
  ==== canvImg-11.1 FAILED



  ==== canvImg-11.3 ImageChangedProc procedure FAILED
  ==== Contents of test case:

      .c delete all
      image create test foo -variable x
      foo changed 0 0 0 0 40 50
      .c create image 50 100 -image foo -tags image -anchor nw
      .c create image 70 110 -image foo2 -anchor nw
      update
      set y {}
      image create test foo -variable x
      update
      set y

  ---- Result was:
  {foo2 display 0 0 20 40 70 110}
  ---- Result should have been (exact matching):
  {foo2 display 0 0 20 40 50 40}
  ==== canvImg-11.3 FAILED

  canvPs.test
  canvRect.test
  canvText.test


  ==== canvText-17.1 TextToPostscript procedure FAILED
  ==== Contents of test case:

      .c delete all
      .c config -height 300 -highlightthickness 0 -bd 0
      update
      .c create text 100 100 -tags test
      .c itemconfig test -font $font -text "00000000" -width [expr 3*$ax]
      .c itemconfig test -anchor n -fill black
      set x [.c postscript]
      set x [string range $x [string first "/Courier-Oblique" $x] end]

  ---- Result was:
  /Courier-Oblique findfont 12 scalefont ISOEncode setfont
  0.000 0.000 0.000 setrgbcolor AdjustColor
  100 200 [
  [(00000000)]
  ] 14 -0.5 0 0 false DrawText
  grestore
  restore showpage

  %%Trailer
  end
  %%EOF

  ---- Result should have been (exact matching):
  /Courier-Oblique findfont 12 scalefont ISOEncode setfont
  0.000 0.000 0.000 setrgbcolor AdjustColor
  100 200 [
  [(000)]
  [(000)]
  [(00)]
  ] 14 -0.5 0 0 false DrawText
  grestore
  restore showpage

  %%Trailer
  end
  %%EOF

  ==== canvText-17.1 FAILED

  canvWind.test
  canvas.test
  choosedir.test
  clipboard.test
  tkMacOSXClipboard.c:76: TkSelGetSelection(): GetScrapFlavorSize failed: -102
  tkMacOSXClipboard.c:102: TkSelGetSelection(): GetScrapFlavorSize failed: -102


  ==== clipboard-4.1 ClipboardLostSel procedure FAILED
  ==== Contents of test case:

      clipboard clear
      clipboard append "Test"
      selection clear -s CLIPBOARD
      list [catch {clipboard get} msg] $msg

  ---- Result was:
  1 {CLIPBOARD GetScrapFlavorSize failed.}
  ---- Result should have been (exact matching):
  1 {CLIPBOARD selection doesn't exist or form "STRING" not defined}
  ==== clipboard-4.1 FAILED

  tkMacOSXClipboard.c:76: TkSelGetSelection(): GetScrapFlavorSize failed: -102
  tkMacOSXClipboard.c:102: TkSelGetSelection(): GetScrapFlavorSize failed: -102


  ==== clipboard-4.2 ClipboardLostSel procedure FAILED
  ==== Contents of test case:

      clipboard clear
      clipboard append "Test"
      clipboard append -t TEST "Test2"
      selection clear -s CLIPBOARD
      list [catch {clipboard get} msg] $msg  [catch {clipboard get -t TEST} msg] $msg

  ---- Result was:
  1 {CLIPBOARD GetScrapFlavorSize failed.} 1 {CLIPBOARD selection doesn't exist or form "TEST" not defined}
  ---- Result should have been (exact matching):
  1 {CLIPBOARD selection doesn't exist or form "STRING" not defined} 1 {CLIPBOARD selection doesn't exist or form "TEST" not defined}
  ==== clipboard-4.2 FAILED

  tkMacOSXClipboard.c:76: TkSelGetSelection(): GetScrapFlavorSize failed: -102
  tkMacOSXClipboard.c:102: TkSelGetSelection(): GetScrapFlavorSize failed: -102


  ==== clipboard-4.3 ClipboardLostSel procedure FAILED
  ==== Contents of test case:

      clipboard clear
      clipboard append "Test"
      clipboard append -t TEST "Test2"
      clipboard append "Test3"
      selection clear -s CLIPBOARD
      list [catch {clipboard get} msg] $msg  [catch {clipboard get -t TEST} msg] $msg

  ---- Result was:
  1 {CLIPBOARD GetScrapFlavorSize failed.} 1 {CLIPBOARD selection doesn't exist or form "TEST" not defined}
  ---- Result should have been (exact matching):
  1 {CLIPBOARD selection doesn't exist or form "STRING" not defined} 1 {CLIPBOARD selection doesn't exist or form "TEST" not defined}
  ==== clipboard-4.3 FAILED



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

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

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

  clrpick.test
  cmds.test
  color.test
  config.test
  tkMacOSXScrlbr.c:130: TkMacOSXInitScrollbarMetrics(): GetThemeMetric failed: -50
  tkMacOSXScrlbr.c:139: TkMacOSXInitScrollbarMetrics(): GetThemeMetric failed: -50
  cursor.test


  ==== cursor-6.83  FAILED
  ==== Contents of test case:

      # Setting fg and bg does nothing for the none cursor
      # because it displays no fg or bg pixels.
      set results [list]
      .b configure -cursor none
      lappend results [.b cget -cursor]
      .b configure -cursor {none blue}
      lappend results [.b cget -cursor]
      .b configure -cursor {none blue green}
      lappend results [.b cget -cursor]
      .b configure -cursor {}
      lappend results [.b cget -cursor]
      set results

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: bad cursor spec "none blue"
      (processing "-cursor" option)
      invoked from within
  ".b configure -cursor {none blue}"
      ("uplevel" body line 7)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: NONE
  ==== cursor-6.83 FAILED

  dialog.test
  embed.test
  entry.test


  ==== entry-1.33 configuration options FAILED
  ==== Contents of test case:

          .e configure $name $goodValue
          list [lindex [.e configure $name] 4] [.e cget $name]
      
  ---- Result was:
  0 0
  ---- Result should have been (exact matching):
  1 1
  ==== entry-1.33 FAILED



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

      .e xview 5
      .e xview

  ---- Result was:
  0.0537634 0.27957
  ---- Result should have been (exact matching):
  0.0537634 0.268817
  ==== entry-3.65 FAILED



  ==== entry-5.7 ConfigureEntry procedure FAILED
  ==== Contents of test case:

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

  ---- Result was:
  0 0.454545
  ---- Result should have been (exact matching):
  0 0.363636
  ==== entry-5.7 FAILED



  ==== entry-13.10 GetEntryIndex procedure FAILED
  ==== Contents of test case:

      # On unix, when selection is cleared, entry widget's internal 
      # selection range is reset.

      list [catch {.e index sel.first} msg] $msg

  ---- Result was:
  0 1
  ---- Result should have been (exact matching):
  1 {selection isn't in widget .e}
  ==== entry-13.10 FAILED



  ==== entry-13.12 GetEntryIndex procedure FAILED
  ==== Contents of test case:

      list [catch {.e index sbogus} msg] $msg

  ---- Result was:
  1 {bad entry index "sbogus"}
  ---- Result should have been (exact matching):
  1 {selection isn't in widget .e}
  ==== entry-13.12 FAILED



  ==== entry-13.21 GetEntryIndex procedure FAILED
  ==== Contents of test case:

      .e index @1000

  ---- Result was:
  10
  ---- Result should have been (exact matching):
  9
  ==== entry-13.21 FAILED



  ==== entry-17.2 EntryUpdateScrollbar procedure FAILED
  ==== Contents of test case:

      .e delete 0 end
      .e insert 0 0123456789abcdef
      .e xview 3
      update
      set scrollInfo

  ---- Result was:
  0.1875 0.875
  ---- Result should have been (exact matching):
  0.1875 0.8125
  ==== entry-17.2 FAILED



  ==== entry-17.3 EntryUpdateScrollbar procedure FAILED
  ==== Contents of test case:

      .e delete 0 end
      .e insert 0 abcdefghijklmnopqrs
      .e xview 6
      update
      set scrollInfo

  ---- Result was:
  0.315789 0.894737
  ---- Result should have been (exact matching):
  0.315789 0.842105
  ==== entry-17.3 FAILED

  event.test


  ==== event-4.1(double-click-drag) click down, click up, click down again, then drag in a text widget FAILED
  ==== Contents of test case:

      destroy .t
      set t [toplevel .t]
      set e [text $t.e]
      pack $e
      tkwait visibility $e
      _keypress_string $e "Word select test"
      set anchor 1.8

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

      # Click down, release, then click down again
      event generate $e <Enter>
      event generate $e <ButtonPress-1> -x $anchor_x -y $anchor_y
      _pause 50
      event generate $e <ButtonRelease-1> -x $anchor_x -y $anchor_y
      _pause 50
      event generate $e <ButtonPress-1> -x $anchor_x -y $anchor_y
      _pause 50

      # Save the highlighted text
      set result [list]
      lappend result [_get_selection $e]

      # Insert cursor should be at beginning of "select"
      lappend result [$e index insert]

      # Move mouse one character to the left
      set current [$e index [list $anchor - 1 char]]
      foreach {current_x current_y} [_text_ind_to_x_y $e $current] break

      event generate $e <B1-Motion> -x $current_x -y $current_y
      _pause 50

      # Insert cursor should be before the l in "select"
      lappend result [$e index insert]

      # Selection should still be the word "select"
      lappend result [_get_selection $e]

      # Move mouse to the space before the word "select"
      set current [$e index [list $current - 3 char]]

      foreach {current_x current_y} [_text_ind_to_x_y $e $current] break
      event generate $e <B1-Motion> -x $current_x -y $current_y
      _pause 200

      lappend result [$e index insert]
      lappend result [_get_selection $e]

      # Move mouse to the r in "Word"
      set current 1.2
      foreach {current_x current_y} [_text_ind_to_x_y $e $current] break

      event generate $e <B1-Motion> -x $current_x -y $current_y
      _pause 50

      # Selection should now be "Word select"
      lappend result [_get_selection $e]

      # Insert cursor should be before the r in "Word"
      lappend result [$e index insert]

      set result

  ---- Result was:
  select 1.5 1.8 select 1.4 { select} {Word select} 1.2
  ---- Result should have been (exact matching):
  select 1.5 1.7 select 1.4 { select} {Word select} 1.2
  ==== event-4.1(double-click-drag) FAILED

  filebox.test


  ==== fileDialog-0.1 GetFileName: file types: MakeFilter() fails FAILED
  ==== Contents of test case:

      # MacOS type that is too long

      set res [list [catch {tk_getSaveFile -filetypes {{"foo" .foo {\0\0\0\0\0}}}} msg] $msg]
      regsub -all "\0" $res {\\0}

  ---- Result was:
  0 /Users/lars/Projekt/Tcl-projekt/Algebra/untitled
  ---- Result should have been (exact matching):
  1 {bad Macintosh file type "\0\0\0\0\0"}
  ==== fileDialog-0.1 FAILED

  Bus error


tkt_uuid: 2207435fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 3 Low
foundin: obsolete: 8.6a4
resolution: Fixed
title: ttk widget aborted construction sequence
comment:
  Something in just the last few days
  of commits to Tk HEAD leads to this:

  $ make shell
  ...
  % ttk::entry .tw -textvariable ::nsn::foo
  can't trace "::nsn::foo": parent namespace doesn't exist
  % X Error of failed request:  BadCursor (invalid Cursor parameter)
    Major opcode of failed request:  1 (X_CreateWindow)
    Resource id in failed request:  0x2600009
    Serial number of failed request:  103
    Current serial number in output stream:  104


  As the example suggests, I discovered
  this as a problem in the ttk test suite
  following test ttk-14.3


tkt_uuid: 220258ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: obsolete: 8.2.2
resolution: Invalid
title: Segmentation fault in strncpy on startup
comment:
  OriginalBugID: 3760 Bug
  Version: 8.2.2
  SubmitDate: '1999-12-03'
  LastModified: '1999-12-16'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  Machine: SunOS  Generic sun4u sparc SUNW,Ultra-1
  ClosedDate: '1999-12-16'


  Name:
  simon blanchard

  CustomShell:
  elide from tkman

  ReproducibleScript:
  ./wish

  It crashes

  ObservedBehavior:
  (gdb) where
  #0  0xfeeb705c in strncpy ()
  #1  0xff00d3ec in _XimMakeImName ()
  #2  0xff00d540 in _XimOpenIM ()
  #3  0xff2c9f78 in OpenIM ()
  #4  0xff2c81c8 in GetScreen ()
  #5  0xff2c7e74 in CreateTopLevelWindow ()
  #6  0xff2c8750 in TkCreateMainWindow ()
  #7  0xff2e40fc in TkCreateFrame ()
  #8  0xff2ca658 in Initialize ()
  #9  0x11998 in Tcl_AppInit ()
  #10 0xff2bcf2c in Tk_MainEx ()
  #11 0x11948 in main ()
  (gdb)

  DesiredBehavior:
  The default wish window should come up



  This appears to be a bug in the X libraries of the users computer.
  The XOpenIM call is defined to accept NULL for string arguments,
  but it appears that the libraries this person is using are not
  taking that into account.  The work-around is to ensure that
  TK_USE_INPUT_METHODS does not get defined in tk.h (comment it out).
  It should have no effect on the users operation if they do not
  require input devices.

  The user should also note that 8.3b1 has elide in core. 
  -- 12/16/1999 hobbs


tkt_uuid: 220346ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 2
foundin: obsolete: 8.0p2
resolution: Fixed
title: wm transient does not map window correctly
comment:
  OriginalBugID: 572 Bug
  Version: 8.0p2
  SubmitDate: '1998-05-11'
  LastModified: '2000-01-06'
  Severity: MED
  Status: Released
  Submitter: stanton
  ChangedBy: hobbs
  RelatedBugIDs: 2710
  OS: All Windows
  FixedDate: '2000-01-06'
  FixedInVersion: 8.3b2


  From: Mark Gammon <m.gammon@fegs.co.uk> 

  I think I have found a bug in the "wm transient" command.
  Try the following:

     toplevel .t
     wm withdraw .t
     wm transient .t .

  The "wm transient" command causes the toplevel to be mapped !

  The culprit seems to be a line of code in tkWInWm.c that
  handles the "wm transient" command:

  line 2056:
      /*
      * Ensure that the transient window is either mapped or 
      * unmapped like its master.
      */


      TkpWmSetState(winPtr, NormalState);

  Commenting this out seems to stop the unwanted mapping and doesn't
  have any bad side-effects as far as I can see.

  The proposed fix is incorrect also.  The correct solution should ensure that the parent state overrides the child state, but that the child state is honored if possible.  For example, if the parent is iconified or unmapped, the child should also be iconified or unmapped.  If the parent is normal, the child should use its own state to determine how to display itself.
  --
  A correct fix is in place for 8.3b2.  If the master is mapped, then
  the transient keeps its state, unless it was Iconic, in which case
  it will become Withdrawn.  If the master is not mapped, the state
  for the transient window will become Withdrawn. 
  -- 01/06/2000 hobbs


tkt_uuid: 1487701fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 74. Application Embedding
priority: 7 High
foundin: obsolete: 8.4.13
resolution: Accepted
title: embedding on OS X Aqua is problematic
comment:
  macosx/tkMacOSXInit.c's TkpInit function is not
  friendly to applications that embed Tcl/Tk.

  One bug is that it only works for the first Tcl
  interpreter that an application creates -- this is not
  a problem for the X11 and Windows versions of Tk.  The
  symptom is that one's ported application crashes
  mysteriously because Apple events refer to a Tcl
  interpreter that no longer exists.

  The next bug appears once the application is rewritten
  to use only one Tcl interpreter (in my case, reuse the
  Tcl interpreter from the splash screen for the main
  part of the application).  Then an extremely helpful
  console window appears (because the application was
  started by double clicking and Tk thinks it was started
  up via Wish.app) that is unwanted and unneeded.  (The
  console appeared before, but quickly disappeared when
  the first Tcl interpreter was destroyed.)  There is no
  reasonable way to disable this behavoir without
  modifying the Tk source code (I want to leave stdin
  alone, thank you very much).


tkt_uuid: 3391905fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: None
resolution: None
title: New themed range widget
comment:
  A TTK widget based on scale that contains two sliders defining a range between two numbers.

  Attached patch is a diff from trunk today.

  Can't find any details on pushing a branch for review or the like...


tkt_uuid: 976928ffffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 01. Bindings
priority: 5 Medium
foundin: TIP Implementation
resolution: Fixed
title: TIP #204: Virtual events for keyboard traversal
comment:
  Attached patch changes tk::TabToWindow to generate
  TraverseIn and TraverseOut virtual events.  A
  forthcoming TIP describes rationale and motivation.


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


tkt_uuid: 3047583fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 06. Canvas Postscript
priority: 5 Medium
foundin: obsolete: 8.5.1
resolution: None
title: line -smooth raw looks funny in Postscript
comment:
  Program-generated cartoon has lines on canvas .c with option -smooth raw such that they render as cubic bezier.

  If there are more than 1 bezier sequence, then the line width varies wildly at the limb points.

  Demonstration: create canvas .c, then source manneken.dump, then say .c postscript, then watch the result.

  Compare with manneken.ps

  If there are questions, mail to wolf-dieter.busch@gmx.de


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


tkt_uuid: 3503317fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 30. Color Names
priority: 5 Medium
foundin: None
resolution: Fixed
title: XParseColor speedup
comment:
  Looking at the XParseColor, there are possibilities
  for speedup which cost nothing (except time to
  implement it)

  - The binary search algorithm keeps track of 3 state
    variables (l, u and i), which can be reduced to 2
    (step and p).
  - The color table contains entries for both entries
    like "aliceBlue" and "alice blue". When we write
    a custom strcasecmp, in which a capital in the
    table matches a space+character in the color
    spec, those two table entries can be combined
    to one.
  - inline FindColor, it's just a small function.

  The measured speedup is about 5%. The color
  table size is reduced from 752 to 657 entries


tkt_uuid: 2107938fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 06. Canvas Postscript
priority: 5 Medium
foundin: obsolete: 8.6a4
resolution: Fixed
title: Mirrored text if Xft is used
comment:
  Hi!

  Appears that if Xft-enabled fonts are used and font size is negative (gives size in pixels, not in points) then canvas postscript prints text inverted (rotated at 180 degrees).

  The problem is that Tk_PostscriptFontName() is expected to return font size in points, but it returns just TkFont size attribute which may be negative.

  The attached patch converts negative size attribute to positive, so canvas postscript becomes working again.


tkt_uuid: 1676672fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
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:

  ==== listbox-4.1 ConfigureListbox procedure FAILED
  ==== Contents of test case:

      catch {destroy .l}
      listbox .l -setgrid 1 -width 25 -height 15
      pack .l
      update
      set x [getsize .]
      .l configure -setgrid 0
      update
      list $x [getsize .]

  ---- Result was:
  25x15 300x250
  ---- Result should have been (exact matching):
  25x15 185x263
  ==== listbox-4.1 FAILED



  ==== listbox-4.6 ConfigureListbox procedure FAILED
  ==== Contents of test case:

      catch {destroy .l}

      # The following code (reset geometry, withdraw, etc.) is necessary
      # to reset the state of some window managers like olvwm under
      # SunOS 4.1.3.

      wm geom . 300x300
      update
      wm geom . {}
      wm withdraw .
      listbox .l -font $fixed -width 15 -height 20
      pack .l
      update
      wm deiconify .
      set x [getsize .]
      .l configure -setgrid 1
      update
      list $x [getsize .]

  ---- Result was:
  300x250 15x20
  ---- Result should have been (exact matching):
  115x328 15x20
  ==== listbox-4.6 FAILED

  ==== listbox-8.1 ListboxEventProc procedure FAILED
  ==== Contents of test case:

      catch {destroy .l}
      listbox .l -setgrid 1
      pack .l
      update
      set x [getsize .]
      destroy .l
      list $x [getsize .] [winfo exists .l] [info command .l]

  ---- Result was:
  20x10 300x250 0 {}
  ---- Result should have been (exact matching):
  20x10 150x178 0 {}
  ==== listbox-8.1 FAILED


tkt_uuid: 220281ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 75. wish
priority: 5 Medium
foundin: obsolete: 8.1a2
resolution: Fixed
title: invalid extern declarations within functions / inconsistancies
comment:
  OriginalBugID: 4209 Bug
  Version: 8.3
  SubmitDate: '2000-02-22'
  LastModified: '2000-02-25'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: All
  ClosedDate: '2000-02-25'


  Name:

  Jan Nijtmans


  ReproducibleScript:

  Just compile Tk 8.3.0 with gcc-2.95.2 and see what happens.


  Further on, the 3 platforms include different test code, depending on the TCL_TEST symbol which is not used in Tk. Looks like some cleaning-up should be done. The patch shows how I think it should be, but I'm not 100% sure.


  ObservedBehavior:

  extern declarations shouldn't occur within function bodies. It's not ANSI-C, and gcc-2.95.2 rightfully complains about it.

  The fact that most other compilers accept it is no excuse.


  Patch:

  *** mac/tkMacAppInit.c.origThu Feb 10 09:53:06 2000

  --- mac/tkMacAppInit.cSat Feb 19 16:24:02 2000

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

  *** 26,42 ****

    #include "tclInt.h"

    #include "tclMac.h"


    #ifdef TK_TEST

    extern intTktest_Init _ANSI_ARGS_((Tcl_Interp *interp));

    #endif /* TK_TEST */


  - #ifdef TCL_TEST

  - extern intProcbodytest_Init _ANSI_ARGS_((Tcl_Interp *interp));

  - extern intProcbodytest_SafeInit _ANSI_ARGS_((Tcl_Interp *interp));

  - extern intTclObjTest_Init _ANSI_ARGS_((Tcl_Interp *interp));

  - extern intTcltest_Init _ANSI_ARGS_((Tcl_Interp *interp));

  - #endif /* TCL_TEST */

  - 

    Tcl_Interp *gStdoutInterp = NULL;


    int TkMacConvertEvent _ANSI_ARGS_((EventRecord *eventPtr));

  --- 26,49 ----

    #include "tclInt.h"

    #include "tclMac.h"


  +     /*

  +      * The following #if block allows you to change the AppInit

  +      * function by using a #define of TCL_LOCAL_APPINIT instead

  +      * of rewriting this entire file.  The #if checks for that

  +      * #define and uses Tcl_AppInit if it doesn't exist.

  +      */

  + 

  + #ifndef TK_LOCAL_APPINIT

  + #define TK_LOCAL_APPINIT Tcl_AppInit    

  + #endif

  +     extern int TK_LOCAL_APPINIT _ANSI_ARGS_((Tcl_Interp *interp));

  + 

  + 

    #ifdef TK_TEST

  + extern intTcltest_Init _ANSI_ARGS_((Tcl_Interp *interp));

    extern intTktest_Init _ANSI_ARGS_((Tcl_Interp *interp));

    #endif /* TK_TEST */


    Tcl_Interp *gStdoutInterp = NULL;


    int TkMacConvertEvent _ANSI_ARGS_((EventRecord *eventPtr));

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

  *** 105,111 ****

         */


        Tcl_FindExecutable(newArgv[0]);

  !     Tk_Main(argc, newArgv, Tcl_AppInit);

    }

    

    /*

  --- 112,118 ----

         */


        Tcl_FindExecutable(newArgv[0]);

  !     Tk_Main(argc, newArgv, TK_LOCAL_APPINIT);

    }

    

    /*

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

  *** 150,172 ****

         * where "Mod" is the name of the module.

         */


  ! #ifdef TCL_TEST

        if (Tcltest_Init(interp) == TCL_ERROR) {

    return TCL_ERROR;

        }

        Tcl_StaticPackage(interp, "Tcltest", Tcltest_Init,

                (Tcl_PackageInitProc *) NULL);

  -     if (TclObjTest_Init(interp) == TCL_ERROR) {

  - return TCL_ERROR;

  -     }

  -     if (Procbodytest_Init(interp) == TCL_ERROR) {

  - return TCL_ERROR;

  -     }

  -     Tcl_StaticPackage(interp, "procbodytest", Procbodytest_Init,

  -             Procbodytest_SafeInit);

  - #endif /* TCL_TEST */

  - 

  - #ifdef TK_TEST

        if (Tktest_Init(interp) == TCL_ERROR) {

    return TCL_ERROR;

        }

  --- 157,168 ----

         * where "Mod" is the name of the module.

         */


  ! #ifdef TK_TEST

        if (Tcltest_Init(interp) == TCL_ERROR) {

    return TCL_ERROR;

        }

        Tcl_StaticPackage(interp, "Tcltest", Tcltest_Init,

                (Tcl_PackageInitProc *) NULL);

        if (Tktest_Init(interp) == TCL_ERROR) {

    return TCL_ERROR;

        }

  *** unix/tkAppInit.c.origThu Dec  2 03:05:39 1999

  --- unix/tkAppInit.cSat Feb 19 16:30:50 2000

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

  *** 24,29 ****

  --- 24,51 ----

    extern int matherr();

    int *tclDummyMathPtr = (int *) matherr;


  +     /*

  +      * The following #if block allows you to change the AppInit

  +      * function by using a #define of TCL_LOCAL_APPINIT instead

  +      * of rewriting this entire file.  The #if checks for that

  +      * #define and uses Tcl_AppInit if it doesn't exist.

  +      */

  + 

  + #ifndef TK_LOCAL_APPINIT

  + #define TK_LOCAL_APPINIT Tcl_AppInit    

  + #endif

  +     extern int TK_LOCAL_APPINIT _ANSI_ARGS_((Tcl_Interp *interp));

  + 

  +     /*

  +      * The following #if block allows you to change how Tcl finds the startup

  +      * script, prime the library or encoding paths, fiddle with the argv,

  +      * etc., without needing to rewrite Tk_Main()

  +      */

  + 

  + #ifdef TK_LOCAL_MAIN_HOOK

  +     extern int TK_LOCAL_MAIN_HOOK _ANSI_ARGS_((int *argc, char ***argv));

  + #endif

  + 

    #ifdef TK_TEST

    extern intTcltest_Init _ANSI_ARGS_((Tcl_Interp *interp));

    extern intTktest_Init _ANSI_ARGS_((Tcl_Interp *interp));

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

  *** 51,76 ****

        int argc;/* Number of command-line arguments. */

        char **argv;/* Values of command-line arguments. */

    {

  -     /*

  -      * The following #if block allows you to change the AppInit

  -      * function by using a #define of TCL_LOCAL_APPINIT instead

  -      * of rewriting this entire file.  The #if checks for that

  -      * #define and uses Tcl_AppInit if it doesn't exist.

  -      */

  -     

  - #ifndef TK_LOCAL_APPINIT

  - #define TK_LOCAL_APPINIT Tcl_AppInit    

  - #endif

  -     extern int TK_LOCAL_APPINIT _ANSI_ARGS_((Tcl_Interp *interp));

  -     

  -     /*

  -      * The following #if block allows you to change how Tcl finds the startup

  -      * script, prime the library or encoding paths, fiddle with the argv,

  -      * etc., without needing to rewrite Tk_Main()

  -      */


    #ifdef TK_LOCAL_MAIN_HOOK

  -     extern int TK_LOCAL_MAIN_HOOK _ANSI_ARGS_((int *argc, char ***argv));

        TK_LOCAL_MAIN_HOOK(&argc, &argv);

    #endif


  --- 73,80 ----

  *** win/winMain.c.origThu Dec  2 03:05:46 1999

  --- win/winMain.cSat Feb 19 16:27:58 2000

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

  *** 34,47 ****

    static voidsetargv _ANSI_ARGS_((int *argcPtr, char ***argvPtr));

    static voidWishPanic _ANSI_ARGS_(TCL_VARARGS(char *,format));


  ! #ifdef TK_TEST

  ! extern intTktest_Init(Tcl_Interp *interp);

  ! #endif /* TK_TEST */


  ! #ifdef TCL_TEST

  ! extern intTclObjTest_Init _ANSI_ARGS_((Tcl_Interp *interp));

    extern intTcltest_Init _ANSI_ARGS_((Tcl_Interp *interp));

  ! #endif /* TCL_TEST */


    static BOOL consoleRequired = TRUE;


  --- 34,65 ----

    static voidsetargv _ANSI_ARGS_((int *argcPtr, char ***argvPtr));

    static voidWishPanic _ANSI_ARGS_(TCL_VARARGS(char *,format));


  !     /*

  !      * The following #if block allows you to change the AppInit

  !      * function by using a #define of TCL_LOCAL_APPINIT instead

  !      * of rewriting this entire file.  The #if checks for that

  !      * #define and uses Tcl_AppInit if it doesn't exist.

  !      */

  ! 

  ! #ifndef TK_LOCAL_APPINIT

  ! #define TK_LOCAL_APPINIT Tcl_AppInit    

  ! #endif

  !     extern int TK_LOCAL_APPINIT _ANSI_ARGS_((Tcl_Interp *interp));

  ! 

  !     /*

  !      * The following #if block allows you to change how Tcl finds the startup

  !      * script, prime the library or encoding paths, fiddle with the argv,

  !      * etc., without needing to rewrite Tk_Main()

  !      */

  ! 

  ! #ifdef TK_LOCAL_MAIN_HOOK

  !     extern int TK_LOCAL_MAIN_HOOK _ANSI_ARGS_((int *argc, char ***argv));

  ! #endif


  ! #ifdef TK_TEST

    extern intTcltest_Init _ANSI_ARGS_((Tcl_Interp *interp));

  ! extern intTktest_Init _ANSI_ARGS_((Tcl_Interp *interp));

  ! #endif /* TK_TEST */


    static BOOL consoleRequired = TRUE;


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

  *** 74,101 ****

        int argc;

        char buffer[MAX_PATH+1];

        char *p;

  -     

  -     /*

  -      * The following #if block allows you to change the AppInit

  -      * function by using a #define of TCL_LOCAL_APPINIT instead

  -      * of rewriting this entire file.  The #if checks for that

  -      * #define and uses Tcl_AppInit if it doesn't exist.

  -      */

  -     

  - #ifndef TK_LOCAL_APPINIT

  - #define TK_LOCAL_APPINIT Tcl_AppInit    

  - #endif

  -     extern int TK_LOCAL_APPINIT _ANSI_ARGS_((Tcl_Interp *interp));

  -     

  -     /*

  -      * The following #if block allows you to change how Tcl finds the startup

  -      * script, prime the library or encoding paths, fiddle with the argv,

  -      * etc., without needing to rewrite Tk_Main()

  -      */

  -     

  - #ifdef TK_LOCAL_MAIN_HOOK

  -     extern int TK_LOCAL_MAIN_HOOK _ANSI_ARGS_((int *argc, char ***argv));

  - #endif


        Tcl_SetPanicProc(WishPanic);


  --- 92,97 ----

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

  *** 189,206 ****

    }

        }


  ! #ifdef TCL_TEST

        if (Tcltest_Init(interp) == TCL_ERROR) {

    return TCL_ERROR;

        }

        Tcl_StaticPackage(interp, "Tcltest", Tcltest_Init,

                (Tcl_PackageInitProc *) NULL);

  -     if (TclObjTest_Init(interp) == TCL_ERROR) {

  - return TCL_ERROR;

  -     }

  - #endif /* TCL_TEST */

  - 

  - #ifdef TK_TEST

        if (Tktest_Init(interp) == TCL_ERROR) {

    goto error;

        }

  --- 185,196 ----

    }

        }


  ! #ifdef TK_TEST

        if (Tcltest_Init(interp) == TCL_ERROR) {

    return TCL_ERROR;

        }

        Tcl_StaticPackage(interp, "Tcltest", Tcltest_Init,

                (Tcl_PackageInitProc *) NULL);

        if (Tktest_Init(interp) == TCL_ERROR) {

    goto error;

        }


  PatchFiles:

  unix/tkAppInit.c win/winMain.c mac/tkMacAppInit.c (talking about naming

      consistancy........)




  We do compile with gcc 2.95.2 and it makes no complaints that are
  mentioned above....  In fact, the comments don't seem correct at all.
  Also, the user is changing Mac files, where gcc is definitely not
  used.  This looks like a bad set of patches. 
  -- 02/25/2000 hobbs


tkt_uuid: 616791ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Duplicate
title: Blinking cursor drawing bug
comment:
  TextBlinkProc() tries to draw the insertion indicator even 
  when it is not visible. The result of TkTextCharBbox() is 
  ignored (it could be -1).

      TkTextCharBbox(textPtr, &index, &x, &y, &w, &h);
      TkTextRedrawRegion(textPtr, x - textPtr-
  >insertWidth / 2, y,
      textPtr->insertWidth, h);


tkt_uuid: 220128ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 39. Image Basics
priority: 1 Zero
foundin: None
resolution: Wont Fix
title: image command may hose existing procedures
comment:
  OriginalBugID: 1338 Bug
  Version: 8.0.4
  SubmitDate: '1999-03-02'
  LastModified: '1999-09-13'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.5.1
  Machine: Other
  ClosedDate: '1999-09-13'


  Name:
  Michael Thomas

  Extensions:
  Itcl3.0.1, Home-made

  CustomShell:
  Jan Nijtman's dash patch was applied to

  ReproducibleScript:
      Run the following script with no arguments.
      
      #!/usr/local/bin/wish8.0
      
      proc image1 {} {
          puts "My image1 called"
      }
      
      image1
      
      image create photo
      
      image1
      
      



  ObservedBehavior:
      The first call to the image1 procedure invokes the user-defined "image1"
      proc.  The second call invokes the image1 command that was automatically
      created by the image command, as indicated by the error message.
      There was no warning or error when the user-defined image1 procedure was
      replaced.
      



  DesiredBehavior:
      When the Tk "image" command is used without supplying a command name, as
      it is above, it will automatically create a new command name.  It should
      check that the automatically created name does not already exist before
      using it, and choose a different name if it does.
      
      If the user specifies a name for the new image command, as in:
      
      image create photo myimageproc
      
      Then the current behaviour seems fine; it is up to the user in this
      case to make sure the command does not already exist.
      
      Similar results are obtained when using the Itcl "class" command.  I
      have
      not yet checked, but the same may also hold true for "open", and any
      other
      command that generates names for new commands. (I hope this was clear).
      
      




  This is a known 'feature' of images, as they are created like
  commands.  proc will also overwrite commands without warning. 
  -- 09/13/1999 hobbs


tkt_uuid: 597920ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 9 Immediate
foundin: obsolete: 8.4b3
resolution: Fixed
title: button appearance/behavior changed
comment:
  In wish 8.4b3,

  % pack [button .b]

  pass the pointer over the button,
  and it will change color (relief?).

  Move the pointer away from the
  button, and it does not change
  back to its original appearance.

  Don't recall seeing this before. 
  Something recent?  Perhaps
  the 2002-08-13 change?


tkt_uuid: 1334613fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 6
foundin: obsolete: 8.5a4
resolution: Fixed
title: -lX11 link order is wrong
comment:
  NetBSD builds of libtk fail to work properly in tclsh
  with [package require Tk].  This also makes it more
  difficult to build a tclkit.  -lX11 is used only when
  building wish.  The proper way to build is to link
  *libtk* with -lX11, so that the runtime linker will be
  able to load all dependencies in the tclkit or tclsh
  cases of [package require Tk]


tkt_uuid: 932155ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 8
foundin: obsolete: 8.4.6
resolution: Fixed
title: Sash misbehavior
comment:
  If you have more than 1 sash (i.e more than 2 panes)
  and a drag is performed on one sash (causing the proxy
  to be placed) and then, on a different sash, a
  <Button-1> event followed by a <ButtonRelease-1> event
  with no intervening <B1-Motion> event, the sash will
  jump to the last proxy location.

  To fix this, the <Button-1> event must initialize the
  proxy location so that if there is no drag, the button
  release will cause no movement of the sash.  This can
  be done by explicitly calling the DragSash function
  from the MarkSash function:

  proc ::tk::panedwindow::MarkSash {w x y proxy} {
      set what [$w identify $x $y]
      if { [llength $what] == 2 } {
  foreach {index which} $what break
  if { !$::tk_strictMotif || [string equal $which
  "handle"] } {
      if {!$proxy} { $w sash mark $index $x $y }
      set ::tk::Priv(sash) $index
      foreach {sx sy} [$w sash coord $index] break
      set ::tk::Priv(dx) [expr {$sx-$x}]
      set ::tk::Priv(dy) [expr {$sy-$y}]
      # Do this to init the proxy location
      DragSash $w $x $y $proxy
  }
      }
  }

  This bug exists on the top of trunk (8.5) as well.

  -Brian


tkt_uuid: 1325998fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 9 Immediate
foundin: obsolete: 8.5a4
resolution: Fixed
title: textWind-10.6.1 freezes
comment:
  textWind-10.6.1 from tk/tests/textWind.test freezes for me.

  Running context:

  tclkit-8.5a4 (build against HEAD)
  OS: Ubuntu linux 2.6.10-5-686
  wm: gnome+metacity 2.10.0


tkt_uuid: 589396ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 5 Medium
foundin: obsolete: 8.4b2
resolution: Duplicate
title: tk_popup incorrectly placment on Windows
comment:
  I noticed that with 8.4, if a tk_popup menu needs to 
  popup at the bottom of the screen, rather than 
  positioning the bottom of the menu at the cursor, it is 
  offset by the menu height. I noticed the code added 
  below for windows in 8.4 which appears to be causing 
  the problem. If I disable the windows check in the code, 
  everything works fine as it did on 8.3.

  This is under Windows 2000.


  proc ::tk::PostOverPoint {menu x y {entry {}}}  {
      global tcl_platform
      if {[string compare $entry {}]} {
  if {$entry == [$menu index last]} {
      incr y [expr {-([$menu yposition $entry] \
      + [winfo reqheight $menu])/2}]
  } else {
      incr y [expr {-([$menu yposition $entry] \
      + [$menu yposition [expr 
  {$entry+1}]])/2}]
  }
  incr x [expr {-[winfo reqwidth $menu]/2}]
      }
      if {$tcl_platform(platform) == "windows"} {
         puts yes
  # We need to fix some problems with menu 
  posting on Windows.
  set yoffset [expr {[winfo screenheight $menu] 
  \
  - $y - [winfo reqheight $menu]}]
  if {$yoffset < 0} {
      # The bottom of the menu is offscreen, so 
  adjust upwards
      incr y $yoffset
      if {$y < 0} { set y 0 }
  }
  # If we're off the top of the screen (either 
  because we were
  # originally or because we just adjusted too 
  far upwards),
  # then make the menu popup on the top 
  edge.
  if {$y < 0} {
      set y 0
  }
      }
      $menu post $x $y
      if {$entry ne "" && [$menu entrycget $entry -state] 
  ne "disabled"} {
  $menu activate $entry
  GenerateMenuSelect $menu
      }
  }


tkt_uuid: 219915ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: -- New Widgets
priority: 1 Zero
foundin: None
resolution: Duplicate
title: Request for more widgets
comment:
  OriginalBugID: 1159 RFE
  Version: 8.0.3
  SubmitDate: '1999-02-02'
  LastModified: '2000-04-16'
  Severity: LOW
  Status: Closed
  Submitter: pat
  ChangedBy: hobbs
  RelatedBugIDs: 1910
  OS: Linux
  Machine: Other
  ClosedDate: '2000-04-16'


  Name:
  Simon Geard

  Extensions:
  Tix tcl+

  CustomShell:
  None

  DesiredBehavior:
  I would like to see the Tix megawidget set subsumed into tk or become a supported extension.


tkt_uuid: 2588919fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 76. Widget Tour
priority: 5 Medium
foundin: None
resolution: Fixed
title: Replace hideous black/white image of JO in demo
comment:
  Now that Tk has PNG in the core, isn't it time to replace the image of J. Ousterhout in the demo with something that doesn't scream "1992"?  This page has a picture of him:

  http://home.pacbell.net/ouster/

  If we want people to realize that Tk can be good looking, that image in the first thing that people are likely to click on in the demo can't be leaving a good impression.  Also, the text ought to be updated to 'creator' rather than 'proprietor'.


tkt_uuid: 679968ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 66. Aqua Window Operations
priority: 4
foundin: obsolete: 8.4.1
resolution: Out of Date
title: Checkbutton text wraps when it shouldn\'t, Aqua
comment:
  Checkbutton text wraps even though the checkbutton is allowed to 
  resize to accomodate the text.

  This happens on Aqua Tk 8.4.1 when the checkbutton font is set 
  to something smaller than the default font.  The following wish 
  script demonstrates the problem.

  wm geometry . 400x100
  checkbutton .b -text {This text should not wrap} -font {system 8}
  pack .b

  The text in the checkbutton is wrapped onto two lines even though 
  there is adequate space for it to be on one line.  Removing the 
  font option causes the text to be displayed on one line with no 
  wrapping.

  The problem appears to be that the checkbutton does not 
  correctly calculate the space needed to display the text on one 
  line when the font is something other than the default font.

  This bug makes preference dialogs with many checkbuttons a 
  mess of wrapped text where no wrapping is needed.

  Tom Goddard
  goddard@cgl.ucsf.edu


tkt_uuid: 1374119fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 68. Win Window Operations
priority: 8
foundin: None
resolution: Fixed
title: keyboard-input charset not initialized correctly on Win32
comment:
  Problem from users' perspective: Windows users of my 
  Tk-based app who    
  have Czech keyboard (CS) set as *default* couldn't  
  input   
  Czech characters into input entries until they switch   
  from CS->EN->CS using the Alt+Shift    
  Windows shortcut (until they do, messy characters   
  appear on the screen instead). After the switching to   
  EN and back everything worked fine (it also  works   
  fine if EN keyboard layout is the default and the   
  user switches to CZ after the app starts).    
      
  Going through the win32 sources, I identified the   
  problem win/tkWinX.c. The best patch I could manage   
  is attached.    
      
  Here's what happens: tkWinX tracks keyboard layout    
  switches by listening to the  Win32   
  WM_INPUTLANGCHANGE event in order to keep its info   
  about the current  input encoding up-to-date. The   
  problem is, that it doesn't initialize its  internal   
  variables according to the initial layout at 
  aplication startup (probably   
  assuming its always EN).   
     
  The patch adds a short code to TkWinXInit that uses   
  GetKeyboardLayout winapi call to determine current   
  keyboard layout, then translates this information   
  into charset code which it uses to update the Tk's   
  variables in the exact same way as WM_INPUTLANGCHANGE   
  event does.   
     
  Please have a look at the patch and consider applying    
  it. The diff is taken against CVS head.   


tkt_uuid: 2112042fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 5 Medium
foundin: obsolete: 8.6a3
resolution: Invalid
title: menu.tcl: error with two arguments called
comment:
  wrong # args: should be "error error"
  wrong # args: should be "error error"
      while executing
  "error $msg $savedInfo"
      (procedure "tk::MbPost" line 115)
      invoked from within
  "tk::MbPost $tk::Priv(inMenubutton) 229 488"
      invoked from within
  "if {$tk::Priv(inMenubutton) ne ""} {
  tk::MbPost $tk::Priv(inMenubutton) 229 488
      }"
      (command bound to event)

  Solution: add quotes...


tkt_uuid: 738143ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 9 Immediate
foundin: obsolete: 8.4.2
resolution: Fixed
title: Vertical paned window demo on Windows
comment:
  If I run the 'vertical paned window demo' all I can 
  see is the horizontal line of the control, which I can 
  click on and drag up and down by a couple of 
  pixels, but I can't actually see either the top or 
  bottom pane at all -- they seem to be of zero 
  height.

  This is on Windows 2000.


tkt_uuid: 526823ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 03. [*button] and [label]
priority: 5 Medium
foundin: obsolete: 8.4a4
resolution: Out of Date
title: Mac OS X Tk 8.4a4:Clicking a checkbutton
comment:
  Mac OS X Tk 8.4a4:Clicking a checkbutton brings an 
  error dialog saying "Can't read Priv(repeated): no 
  such variable".  

  How to reproduce:
  Enter the following scrpt on Console"
  checkbutton .cb -text "Hello"
  pack .cb

  Then click the button on Wish Shell.

  Here is the error log.
  can't read "Priv(repeated)": no such variable
  can't read "Priv(repeated)": no such variable
      while executing
  "if { $Priv(repeated) == 0 } {
          uplevel #0 [list $w invoke]
          }"
      (procedure "tk::ButtonUp" line 18)
      invoked from within
  "tk::ButtonUp .dummy.gui.options.printidentical"
      (command bound to event)

  System I'm using is Mac OS X 10.1.3.


tkt_uuid: 220435ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 2
foundin: final: 8.0.5
resolution: Fixed
title: tk_messageBox underlines 1st char of buttons but doesn't act when that char is pressed
comment:
  OriginalBugID: 1292 Bug
  Version: 8.0.5
  SubmitDate: '1999-02-24'
  LastModified: '1999-08-15'
  Severity: LOW
  Status: Released
  Submitter: admin
  ChangedBy: hobbs
  RelatedBugIDs: 1293
  OS: All Unix
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-15'
  FixedInVersion: 8.2


  I can't find any way to press 'y' to invoke the "Yes" button in the following example:

      tk_messageBox -type yesno -default no

  After moving my mouse over the messageBox window, I tried ctrl-y, shift-y, ctrl-shift-y, alt-y, alt-shift-y, and tabbing to the "Yes" button.  Since "No" is the default, pressing return after any of these actions invoked "no".  If I remove the default,

      tk_messageBox -type yesno

  the same behavior occurs, except that the returns are ignored too.



  This functionality works as expected in 8.2.0 message boxes
  on Windows and Unix using Alt-<char>. 
  -- 08/15/1999 hobbs


tkt_uuid: 1630271fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 8
foundin: obsolete: 8.5.10
resolution: Fixed
title: segfault/infinite loop when a mark is before -startline
comment:
  Normally you can't access characters before -startline because "1.0" refers to the beginning of -startline. But marks get around that little hindrance!

  pack [text .t] -side top
  .t insert end "1\n2\n3\n"
  .t mark set insert 1.0
  .t conf -startline 2

  # This gives a weird result, "0.0"
  .t index insert

  # This will segfault
  .t index insert-1c

  # This will infinite loop and gobble up all yer memory
  .t get insert


tkt_uuid: 3603436fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 41. Photo Images
priority: 8
severity: Minor
foundin: current: 8.6.0
resolution: None
title: png save has wrong component indexes in Tk8.6
comment:
  I create a new PNG photo image from Tk and then fill it from C with Tk_PutPhotoBlock. Writing it to file then results in wrong color component indexes. It seems to put the RGBA indexes (blockPtr->offset) in function EncodePNG as 1 2 3 3 when after some tracing into the code should really be 1 2 3 0. (not sure why it is not (0 1 2 3) though


tkt_uuid: 588831ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 69. Events
priority: 5 Medium
foundin: obsolete: 8.3.4
resolution: Fixed
title: Free memory read in GenerateFocusEvents
comment:
  Running purify, I ran across a situation which I
  believe has been causing intermittent crashes in our
  application regression tests.  Here's the scenerio: 
  The application has three toplevel windows, ".",
  ".signals", and ".dataflow".   As part of the exit code
  the two toplevel windows, ".signals" and ".dataflow"
  are destroyed.  Free memory reads and writes occur
  while processing background events after the windows
  have been destroyed.  This happens because the focus is
  passed from ".signals" to ".dataflow" when ".signals"
  is really deleted, but ".dataflow" has already been
  marked for removal.  Later, the queued FocusIn event is
  processed, but at this point the ".dataflow" window is
  finally gone and the window ptr has been free'd.  

  I don't have a simple test case for this that can run
  in wish.  I suspect the situation is timing critical
  and changes based on other queued activity.

  The attached patch will prevent the queing of dead windows.

  -Brian


tkt_uuid: 2239034fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 68. Win Window Operations
priority: 8
foundin: None
resolution: Fixed
title: [wm manage] failure with ttk::frames
comment:
  [wm manage] seems not to work with [ttk::frame]s. (It doesn't seem to be working right for other widgets, actually - see below.) Tk [frame]s work fine. I'm using TclKit 8.5.2 on Windows XP SP3. Example:

  % ttk::frame .f
  .f
  % button .f.b -text "Test"
  .f.b
  % pack .f.b
  % wm manage .f

  At this point, nothing noticable has happened - there isn't a new toplevel window created for .f

  If I then do

  % wm forget .f
  % pack .f

  I see my "Test" button appear in the absolute top left-hand corner of my screen (not in a window - floating loose). If I attempt to interact with it it vanishes instantly. It seems that space is allocated for the frame in . when I try to [pack] it, though - repeat the above with a [text] widget instead of a [button] and you'll see . grow to accomodate it, even though it doesn't actually pack it. (This isn't specific to [pack], either - I first noticed it in a panewindow)

  If I try [wm manage] with other Tk widgets (I've tried [button] and [text]), I still don't get a toplevel, but if I [wm forget $tkWidget] and then [pack $tkWidget], it does pack correctly. Other Ttk widgets seem to have the same issue as a ttk::frame.

  So, it seems like only [frame]s can be successfully [wm manage]'d. (I actually remember reading it that way when I first heard about [wm manage] being added, but it seems not to be what the documentation at http://www.tcl.tk/man/tcl8.5/TkCmd/wm.htm#M39 says, so not sure whether this is a code error or a documentation fault. Though if it is only meant to work for frames, it should probably error for other widgets?)


tkt_uuid: 614650ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 8
foundin: obsolete: 8.4.0
resolution: Fixed
title: Tk crashes when pasting large selections
comment:
  When a selection of more than 3999 bytes gets pasted
  from a Tk text widget into e.g. vi running inside
  xterm, wish crashes with a segfault.

  This can be reproduced by the following script:

  pack [text .t] -expand yes -fill both
  .t insert end [string repeat a 4000]

  Select the whole content of the text widget by
  double-click and try to paste it elsewhere. I observed
  this crash on SuSE Linux 8.0, and 8.1 under fvwm2 and
  windowmaker.

  The following little patch fixes the segfault, but
  pasting selections > 3999 bytes still doesn't work
  after applying it.

  --- tkUnixSelect.c      2002/09/25 21:03:59     1.1
  +++ tkUnixSelect.c      2002/09/25 21:25:58
  @@ -469,7 +469,7 @@
                          eventPtr->xproperty.window,
                          eventPtr->xproperty.atom,
  formatType, 8,
                          PropModeReplace,
  -                       (unsigned char *)
  Tcl_DStringValue(&ds), numItems);
  +                       propPtr, numItems);
                  Tk_DeleteErrorHandler(errorHandler);
   
                  ckfree(propPtr);


tkt_uuid: 745965ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5a0
resolution: Fixed
title: Potential read of deallocated mem?
comment:
  As I was building a test version of Tk, I noticed that
  in (version 1.16 of) tkTextDisp.c the variable 'flags'
  at line 2247 was unused in the function DisplayText. 
  Further investigation of that code suddenly had an
  unused variable indicated to me that there seems to be
  a potential for trying to read from a deallocated
  structure, which could happen if the Tcl_Release call
  at line 2253, when testing for whether a delete had
  happened on line 2254.  Is this really the case?  It
  seems unfortunate if it is so, but if it can be proved
  to be not a problem, then perhaps the Tcl_Preserve /
  Tcl_Release pair are not needed (though I suspect they
  are, given that they are around something that can
  trigger events/callbacks...)


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

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

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

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

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

  I cannot imagine how this behavior could be by design.


tkt_uuid: 3555211fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 83. Mac OS X Build
priority: 5 Medium
foundin: obsolete: 8.5.12
resolution: Fixed
title: Cocoa 8.5.12 backport crashes when using clipboard copy
comment:
  With the OS X Cocoa backport of Tcl/Tk 8.5.12 (as seen in ActiveTcl 8.5.12 for OS X), attempting to use clipboard Copy with a text widget causes an immediate crash in the interpreter.  This is a serious regression from 8.5.11.

  See discussion on tcl-mac list beginning here:
  https://sourceforge.net/mailarchive/message.php?msg_id=29646437


tkt_uuid: 895899ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 84. Unix Build
priority: 5 Medium
foundin: obsolete: 8.4.5
resolution: Invalid
title: Search order for the tclConfig.sh
comment:
  I'm having troubles when installing Tcl/Tk on Solaris into
  non-standard location. configure/build of the Tcl went
  fine but configure for the Tk fails whith
   "Use --with-tcl= option ...". 
  The problem is that I have an old version installed in 
  /usr/local. Last time I checked (8.3.*) Tk's configure 
  used to check --prefix location first.

  It is not really a bug, but the old behaviour was much
  more convenient IMHO.


tkt_uuid: 582371ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.4.1
resolution: Fixed
title: several textWind tests fail on Win.
comment:
  These tests fail in 8.4b2:

  textWind.test

  ==== textWind-10.1 EmbWinLayoutProc procedure 
  FAILED
  ==== Contents of test case:

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

  ---- Result was:
  1 10x20+45+5 1.5
  ---- Result should have been (exact matching):
  1 10x20+40+5 1.5
  ==== textWind-10.1 FAILED


  ==== textWind-10.11 EmbWinLayoutProc 
  procedure, doesn't fit on line FAILED
  ==== Contents of test case:

      .t configure -wrap none
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 130 -height 20 -bg $color -bd 
  2 -relief raised
      .t window create 1.12 -window .f
      update
      list [.t bbox .f] [.t bbox 1.13]

  ---- Result was:
  {101 5 130 20} {231 6 8 17}
  ---- Result should have been (exact matching):
  {89 5 126 20} {}
  ==== textWind-10.11 FAILED


  ==== textWind-11.1 EmbWinDisplayProc 
  procedure, geometry transforms FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      pack forget .t
      place .t -x 30 -y 50
      frame .f -width 30 -height 20 -bg $color
      .t window create 1.12 -window .f
      update
      winfo geom .f

  ---- Result was:
  30x20+131+55
  ---- Result should have been (exact matching):
  30x20+119+55
  ==== textWind-11.1 FAILED


  ==== textWind-11.2 EmbWinDisplayProc 
  procedure, geometry transforms FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      pack forget .t
      place .t -x 30 -y 50
      frame .t.f -width 30 -height 20 -bg $color
      .t window create 1.12 -window .t.f
      update
      winfo geom .t.f

  ---- Result was:
  30x20+101+5
  ---- Result should have been (exact matching):
  30x20+89+5
  ==== textWind-11.2 FAILED


  ==== textWind-13.1 EmbWinBboxProc procedure 
  FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 5 -height 5 -bg $color
      .t window create 1.2 -window .f -align top -
  padx 2 -pady 1
      update
      list [winfo geom .f] [.t bbox .f]

  ---- Result was:
  5x5+23+6 {23 6 5 5}
  ---- Result should have been (exact matching):
  5x5+21+6 {21 6 5 5}
  ==== textWind-13.1 FAILED


  ==== textWind-13.2 EmbWinBboxProc procedure 
  FAILED
  ==== Contents of test case:

      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 5 -height 5 -bg $color
      .t window create 1.2 -window .f -align center -
  padx 2 -pady 1
      update
      list [winfo geom .f] [.t bbox .f]

  ---- Result was:
  5x5+23+11 {23 11 5 5}
  ---- Result should have been (exact matching):
  5x5+21+9 {21 9 5 5}
  ==== textWind-13.2 FAILED


  ==== textWind-13.9 EmbWinBboxProc procedure, 
  spacing options FAILED
  ==== Contents of test case:

      .t configure -spacing1 5 -spacing3 2
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 5 -height 5 -bg $color
      .t window create 1.2 -window .f -align center -
  padx 2 -pady 1
      update
      list [winfo geom .f] [.t bbox .f]

  ---- Result was:
  5x5+23+16 {23 16 5 5}
  ---- Result should have been (exact matching):
  5x5+21+14 {21 14 5 5}
  ==== textWind-13.9 FAILED


  ==== textWind-16.2 EmbWinTextStructureProc 
  procedure FAILED
  ==== Contents of test case:

      .t configure -wrap none
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .f -width 30 -height 20 -bg $color
      .t window create 1.6 -window .f
      update
      set result {}
      lappend result [winfo geom .f] [.t bbox .f]
      frame .f2 -width 150 -height 30 -bd 2 -relief 
  raised
      pack .f2 -before .t
      update
      lappend result [winfo geom .f] [.t bbox .f]

  ---- Result was:
  30x20+53+5 {53 5 30 20} 30x20+53+35 {53 5 30 
  20}
  ---- Result should have been (exact matching):
  30x20+47+5 {47 5 30 20} 30x20+47+35 {47 5 30 
  20}
  ==== textWind-16.2 FAILED


  ==== textWind-16.4 EmbWinTextStructureProc 
  procedure FAILED
  ==== Contents of test case:

      .t configure -wrap none
      .t delete 1.0 end
      .t insert 1.0 "Some sample text"
      frame .t.f -width 30 -height 20 -bg $color
      .t window create 1.6 -window .t.f
      update
      pack forget .t
      update
      list [winfo ismapped .t.f] [.t bbox .t.f]

  ---- Result was:
  1 {53 5 30 20}
  ---- Result should have been (exact matching):
  1 {47 5 30 20}
  ==== textWind-16.4 FAILED


tkt_uuid: 1176605fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 65. Generic Window Operations
priority: 4
foundin: obsolete: 8.5a3
resolution: Fixed
title: wm attributes -notify docs missing
comment:
  In CVS, 8.5a3 has the Aqua patch to implement the
  [wm attributes -notify] option, but it isn't documented,
  and the option isn't listed in the invalid arguments
  message.  I've included a patch below to fix this.


tkt_uuid: 219373ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 99. Other
priority: 7 High
resolution: None
title: Tcl core dumps after several hours
comment:
  OriginalBugID: 5995 Bug
  Version: 8.3.1
  SubmitDate: '2000-07-10'
  LastModified: '2000-07-17'
  Severity: CRIT
  Status: UnAssn
  Submitter: techsupp
  ChangedBy: ericm
  OS: Windows NT
  OSVersion: Windows NT 4.0
  Machine: Dell Dimension XPST550, 128M RAM
  FixedDate: '2000-10-25'
  ClosedDate: '2000-10-25'


  Name:
  Yukari Cash

  Extensions:
  Tix 4.1.8.2  from Iain Findleton

  CustomShell:
  None.

  Comments:
  The problem occurs with tcl/tk 8.2.x and tcl/tk 8.3.1.  
      The problem did not occur with tcl/tk8.0.

      This is an urgent matter, as we have customers waiting for the new
      version of our application.  We are unable to release the new version as
      long as tcl/tk core dumps.

  ReproducibleScript:
  Our application is very large and it would be difficult for you to replicate the problem without special test equipment.  If necessary, I could provide a sample application which recreates the problem without the need for any special equipment.  This won't be easy, so I'm hoping the stack trace is sufficient to identify the problem.

  ObservedBehavior:
  Our application uses Tcl/Tk and users run the application anywhere from a few minutes to overnight.  The application runs fine up to 1.5 to 2 hours.  After several hours (approximately 2 hours), Tcl/Tk core dumps with, for example:
  "Instruction at 0x0099a07f referenced memory at 0x00000000. The memory could not be read."

  Here is the stack trace:
  TkWinGetDrawableDC(_XDisplay * 0x00177a18, unsigned long 0, TkWinDCState * 0x0012c994) line 158 + 3 bytes
  XCopyArea(_XDisplay * 0x00177a18, unsigned long 0, unsigned long 45575632, XGCValues * 0x023d4640, int 30, int 30, unsigned int 56, unsigned int 530, int 32, int 1) line 317 + 17 bytes
  DisplayCanvas(int * 0x02a1abd0) line 2364 + 95 bytes
  TclServiceIdle() line 692 + 12 bytes
  Tcl_DoOneEvent(int -1) line 923 + 5 bytes
  Tk_UpdateObjCmd(int * 0x0014d7b8, Tcl_Interp * 0x001449a8, int 1, Tcl_Obj * const * 0x00154a08) line 889 + 16 bytes
  TclExecuteByteCode(Tcl_Interp * 0x001449a8, ByteCode * 0x03c57cb0) line 846 + 34 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x001449a8, Tcl_Obj * 0x02924418, int 0) line 2733 + 13 bytes
  TclObjInterpProc(int * 0x02924718, Tcl_Interp * 0x001449a8, int 6, Tcl_Obj * const * 0x001549f0) line 1001 + 21 bytes
  TclExecuteByteCode(Tcl_Interp * 0x001449a8, ByteCode * 0x03bf2bf0) line 846 + 34 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x001449a8, Tcl_Obj * 0x02923898, int 0) line 2733 + 13 bytes
  TclObjInterpProc(int * 0x02923998, Tcl_Interp * 0x001449a8, int 3, Tcl_Obj * const * 0x0012d864) line 1001 + 21 bytes
  EvalObjv(Tcl_Interp * 0x001449a8, int 3, Tcl_Obj * const * 0x0012d864, char * 0x039388a0, int 26, int 0) line 932 + 25 bytes
  Tcl_EvalEx(Tcl_Interp * 0x001449a8, char * 0x039388a0, int 26, int 262144) line 1393 + 30 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x001449a8, Tcl_Obj * 0x03aecc00, int 262144) line 2580 + 21 bytes
  Tcl_UplevelObjCmd(int * 0x00000000, Tcl_Interp * 0x001449a8, int 1, Tcl_Obj * const * 0x001549ec) line 604 + 20 bytes
  TclExecuteByteCode(Tcl_Interp * 0x001449a8, ByteCode * 0x038caf40) line 846 + 34 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x001449a8, Tcl_Obj * 0x028fc3e0, int 0) line 2733 + 13 bytes
  TclObjInterpProc(int * 0x028fc9e0, Tcl_Interp * 0x001449a8, int 2, Tcl_Obj * const * 0x001549e0) line 1001 + 21 bytes
  TclExecuteByteCode(Tcl_Interp * 0x001449a8, ByteCode * 0x03becbe0) line 846 + 34 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x001449a8, Tcl_Obj * 0x02313a40, int 0) line 2733 + 13 bytes
  TclObjInterpProc(int * 0x02313840, Tcl_Interp * 0x001449a8, int 2, Tcl_Obj * const * 0x001549d8) line 1001 + 21 bytes
  TclExecuteByteCode(Tcl_Interp * 0x001449a8, ByteCode * 0x03c02410) line 846 + 34 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x001449a8, Tcl_Obj * 0x023137c0, int 0) line 2733 + 13 bytes
  TclObjInterpProc(int * 0x023135c0, Tcl_Interp * 0x001449a8, int 1, Tcl_Obj * const * 0x001549d4) line 1001 + 21 bytes
  TclExecuteByteCode(Tcl_Interp * 0x001449a8, ByteCode * 0x03a95dd0) line 846 + 34 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x001449a8, Tcl_Obj * 0x02a6b670, int 131072) line 2733 + 13 bytes
  TkInvokeButton(TkButton * 0x02a195c0) line 1467 + 33 bytes
  ButtonWidgetObjCmd(int * 0x02a195c0, Tcl_Interp * 0x001449a8, int 2, Tcl_Obj * const * 0x03cb6bb0) line 842 + 9 bytes
  EvalObjv(Tcl_Interp * 0x001449a8, int 2, Tcl_Obj * const * 0x03cb6bb0, char * 0x0098443c, int 0, int 262144) line 932 + 25 bytes
  Tcl_EvalObjv(Tcl_Interp * 0x001449a8, int 2, Tcl_Obj * const * 0x03cb6bb0, int 262144) line 1019 + 32 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x001449a8, Tcl_Obj * 0x03ac6730, int 262144) line 2576 + 27 bytes
  Tcl_UplevelObjCmd(int * 0x00000000, Tcl_Interp * 0x001449a8, int 1, Tcl_Obj * const * 0x001549d0) line 604 + 20 bytes
  TclExecuteByteCode(Tcl_Interp * 0x001449a8, ByteCode * 0x038d6d50) line 846 + 34 bytes
  Tcl_EvalObjEx(Tcl_Interp * 0x001449a8, Tcl_Obj * 0x00226138, int 0) line 2733 + 13 bytes
  TclObjInterpProc(int * 0x002261b8, Tcl_Interp * 0x001449a8, int 2, Tcl_Obj * const * 0x0012f8bc) line 1001 + 21 bytes
  EvalObjv(Tcl_Interp * 0x001449a8, int 2, Tcl_Obj * const * 0x0012f8bc, char * 0x0012fad4, int 34, int 0) line 932 + 25 bytes
  Tcl_EvalEx(Tcl_Interp * 0x001449a8, char * 0x0012fad4, int 34, int 0) line 1393 + 30 bytes
  Tcl_Eval(Tcl_Interp * 0x001449a8, char * 0x0012fad4) line 1512 + 17 bytes
  Tcl_GlobalEval(Tcl_Interp * 0x001449a8, char * 0x0012fad4) line 4149 + 13 bytes
  Tk_BindEvent(Tk_BindingTable_ * 0x001479a8, _XEvent * 0x03b956d8, Tk_Window_ * 0x02a169c0, int 0, int * * 0x0012fbf4) line 1775 + 23 bytes
  TkBindEventProc(TkWindow * 0x02a169c0, _XEvent * 0x03b956d8) line 245 + 31 bytes
  Tk_HandleEvent(_XEvent * 0x03b956d8) line 737 + 13 bytes
  WindowEventProc(Tcl_Event * 0x03b956d0, int -3) line 1072 + 12 bytes
  Tcl_ServiceEvent(int -3) line 607 + 11 bytes
  Tcl_DoOneEvent(int -3) line 910 + 9 bytes
  Tk_MainLoop() line 1130 + 13 bytes
  Tk_MainEx(int 1, char * * 0x00134770, int (Tcl_Interp *)* 0x0042fb8e Tcl_AppInit(Tcl_Interp *), Tcl_Interp * 0x001449a8) line 282
  WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00132a5f, int 1) line 150 + 26 bytes
  WinMainCRTStartup + 319 bytes
  KERNEL32! 77f1b9ea()

  DesiredBehavior:
  No core dumps.



  We need more information.  Can you tell us what is being displayed on the canvas at the time of the crash, and give us a general feel for what the application is doing?

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

  -- 07/17/2000 ericm


tkt_uuid: 3462883fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 12. Unix Menus
priority: 5 Medium
foundin: obsolete: 8.5.9
resolution: None
title: tearoff iconifys on loss of focus
comment:
  When a popup menu is torn off, the resultant menu is iconified if the parent loses focus.  This is a problem particularly if the tearoff is moved outside of the parent window, in which case it is very hard to get focus back to the menu.  A simple case:
  menu .foo -tearoff 1
  .foo add command -label "foov"
  bind . <3> "tk_popup .foo %X %Y

  The right click in the window and do the tear off.  When the mouse leaves the main window the tearoff will iconify.

  By the way, this does not happen on Windows systems.


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

  Example:

  set FileName [tk_getOpenFile -initialfile example.txt]

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

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

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

  Furthermore, file types are ignored. Thus even

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

  is specified, all files in the directory are listed.

  Peter Balling
  pballing@asc-consult.com


tkt_uuid: 600313ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 37. [tk_get*File]
priority: 5 Medium
foundin: obsolete: 8.4b1
resolution: None
title: Several problems with tkfbox.tcl
comment:
  - I find the FocusIn binding disturbing. If I move
  accidently the cursor out o f the dialog after
  painfully selecting some multiple items, everything is
  lost (I have a FocusFollowsMouse window manager). I
  think it's better to disable the FocusIn and FocusOut
  bindings.

  - There should be nop bindings for Control-B1-Motion,
  Shift-B1-Motion, Control-Double-ButtonRelease-1 and
  Shift-Double-ButtonRelease-1. If multiple items are
  selected and while pressing the control key I do a
  little horizontal movement, all items are deselected.

  - In the IconList_Selection proc there is obviously a
  [incr ind] missing, somewhere around line 107.

  - Is there any reason why Curselection has a lowercase
  "s" while DrawSelection has a uppercase "s"?

  - In IconList_Arrange, a final call to
  IconList_DrawSelection is missing. Otherwise the
  selection will not be correctly redrawn if the window
  is resized.

  - If multiple directories are opened, day /a and /b,
  then tkfbox.tcl seems to chdir first to /a and then
  tries to open b in this directory, which of course
  fails.

  - All references to data(curItem) may be deleted, as
  it's not used anymore.


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


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

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

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


tkt_uuid: 979101ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 37. [tk_get*File]
priority: 6
foundin: None
resolution: Accepted
title: Env vars in tk_getOpenFile Filename entry?
comment:
  The tk_getOpenFile Filename entry interprets ~/filename 
  as a file in the user's home directory. It would be nice to 
  have environment variables also. eg $HOME/filename.

  Is this something that "should" be done? I suspect 
  windows env vars would be specified in the windows 
  format.

  Would you accept donated code for it? (provided I can 
  find time to do it of course) 


tkt_uuid: 912571ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 54. [console]
priority: 9 Immediate
foundin: obsolete: 8.4.13
resolution: Fixed
title: wish crashing during exit when stdin is closed.
comment:
  Steps to reproduce:

  1. On Windows, run wish (either 8.4 or 8.5 will do).
  2. In the console window, evaluate "close stdin".
  3. Close the Tk app window.
  4. Crash.

  DeleteChannelTable(void * 0x01026480, Tcl_Interp * 
  0x00ffb838) line 600 + 3 bytes
  DeleteInterpProc(Tcl_Interp * 0x00ffb838) line 1055 + 
  18 bytes
  Tcl_EventuallyFree(void * 0x00ffb838, void (char *)* 
  0x10012771 DeleteInterpProc(Tcl_Interp *)) line 311 + 9 
  bytes
  Tcl_DeleteInterp(Tcl_Interp * 0x00ffb838) line 943 + 14 
  bytes
  ConsoleDeleteProc(void * 0x00f3ef38) line 699 + 19 
  bytes
  Tcl_DeleteCommandFromToken(Tcl_Interp * 
  0x008cade8, Tcl_Command_ * 0x00f224e0) line 2552 + 
  15 bytes
  TclTeardownNamespace(Namespace * 0x008ccde8) line 
  956 + 13 bytes
  DeleteInterpProc(Tcl_Interp * 0x008cade8) line 1005 + 
  12 bytes
  Tcl_EventuallyFree(void * 0x008cade8, void (char *)* 
  0x10012771 DeleteInterpProc(Tcl_Interp *)) line 311 + 9 
  bytes
  Tcl_DeleteInterp(Tcl_Interp * 0x008cade8) line 943 + 14 
  bytes
  Tk_MainEx(int 1, char * * 0x008d0060, int (Tcl_Interp *)
  * 0x004010f3 Tcl_AppInit(Tcl_Interp *), Tcl_Interp * 
  0x008cade8) line 303 + 18 bytes
  WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 
  0x00000000, char * 0x00133750, int 1) line 129 + 37 
  bytes
  WinMainCRTStartup() line 330 + 54 bytes
  KERNEL32! GetProcessPriorityBoost + 279 bytes


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

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

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

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

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

  yields

  font A
  font A
  font A
    :

  if the problem exists, and 

  font Arial
  font Arial Baltic
  font Arial Black
          :

  if it doesn't.  

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

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

  Hope this helps.  

          Rick


tkt_uuid: 220930ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 41. Photo Images
priority: 5 Medium
foundin: None
resolution: Fixed
title: Discovering the transparent area of a photo image
comment:
  OriginalBugID: 5947 RFE
  Version: 8.4a1
  SubmitDate: '2000-06-26'
  LastModified: 
  Severity: LOW
  Status: UnAssn
  Submitter: techsupp
  OS: All Unix


  Name:
  Donal K. Fellows

  Comments:
  This will allow me to create a version of my shaped-window extension
      where windows are shaped to the outlines specified in transparent photo
      images, a feature that would make writing advanced drag-and-drop support
      much easier.  While it is possible to hack the info needed out of the
      relevant internal structure, this would be highly fragile and liable to
      break if anyone ever changed the implementation of photo images at all.

  DesiredBehavior:
  A function (to be in the tkInt interface due to typing restrictions) to allow extensions to discover what parts of a photo image are transparent.

  Patch:
  http://www.cs.man.ac.uk/~fellowsd/tcl/validRegion.patch

  PatchFiles:
  tkImgPhoto.c
      tkInt.decls
      tkIntDecls.h
      tkStubInit.c


tkt_uuid: 1311734fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 74. Application Embedding
priority: 5 Medium
foundin: obsolete: 8.5a4
resolution: Fixed
title: Embedded windows fail to response to Windows display changes
comment:
  The following scripts show the problem:

  pack [frame .f -container 1]
  set id [winfo id .f]
  toplevel .t -use $id
  button .t.b -text Button -comm "puts ..."
  pack .t.b

  # 
  # change the display to a different depth and find 
  # the button become black.
  # The same problem also occures in all previous 
  # Tk versions (Windows)
  #


tkt_uuid: 2993702fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Works For Me
title: Rotated text on canvas grows larger
comment:
  When a text string is rotated on the canvas (in this case, to 90 degrees), it gets noticeably larger.  When it's rotated back to 0 degrees, a portion of the text is not properly removed from the screen.  The size of that remaining portion seems to be the difference between the original text size and the now-too-large text size after rotation.

  So, for instance, if the original string was 100 pixels wide, it might be 120 pixels high after rotation.  When it's rotated back to horizontal, a 20 pixel piece (in this example) would be left behind.  

  Win 7, x64, AS 8.6b1.1

  The attached image should help to explain things better.


tkt_uuid: 3611174fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 05. Canvas Items
priority: 7 High
foundin: current: 8.6.0
resolution: None
title: Empty text items aren't found by "find enclosed"
comment:
  Empty text items aren't found by "find enclosed". Tcl/Tk 8.4.19 and 8.5.2 don't have the bug.
  Script:
  -----
  catch {console show}
  canvas .c
  grid .c
  puts [info patchlevel]
  set item [.c create text 100 100 -text "1"]
  puts "Enclosed: [.c find enclosed 0 0 10000 10000]"
  .c itemconfigure $item -text ""
  puts "Enclosed: [.c find enclosed 0 0 10000 10000]"
  -----
  Result:
  8.6.0
  Enclosed: 1
  Enclosed:


tkt_uuid: 220397ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 09. [listbox]
priority: 2
foundin: obsolete: 8.0.3
resolution: Fixed
title: listbox extended mode script bug
comment:
  OriginalBugID: 866 Bug
  Version: 8.0.3
  SubmitDate: '1998-11-25'
  LastModified: '1999-08-06'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: All
  OSVersion: NA
  Machine: NA
  FixedDate: '1999-08-06'
  FixedInVersion: 8.2


  Date: Wed, 4 Nov 1998 12:01:45 -0800 (PST)

  To: tclsupport@scriptics.com

  Subject: listbox extended mode script bug

  From: rembleton@hilbertsoft.com



  Tk 8.0.3 Bug



  email:  rembleton@hilbertsoft.com

  Support:  None

  Severity:  2

  OperatingSystem:  Windows NT

  OperatingSystemVersion:  4.0 SR3

  Synopsis:  listbox extended mode script bug



  ReproducibleScript:

  ## enter the following in the wish console



  entry .e

  listbox .lb -selectmode extended

  pack .e .lb

  .lb insert end 1

  .lb insert end 2



  ## set the focus in .e

  ## tab to .lb

  ## press Shift-Down





  ObservedBehavior:

  Since there is no selection, the tk code fails and generates the following:



  bad listbox index "": must be active, anchor, end, @x,y, or a number

      while executing

  "$w selection clear $i $el"

      ("extended" arm line 7)

      invoked from within

  "switch [$w cget -selectmode] {

  browse {

      $w selection clear 0 end

      $w selection set $el

      set tkPriv(listboxPrev) $el

  }

  extended {

      ..."

      (procedure "tkListboxMotion" line 7)

      invoked from within

  "tkListboxMotion $w [$w index active]"

      (procedure "tkListboxExtendUpDown" line 7)

      invoked from within

  "tkListboxExtendUpDown .lb -1"

      (command bound to event)





  DesiredBehavior:

  the system should select the first two elements of the listbox





  Fixed in 8.2b3 release. 
  -- 08/06/1999 hobbs


tkt_uuid: 1550523fffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 36. [tk_chooseDirectory]
priority: 5 Medium
foundin: None
resolution: None
title: Make tk_chooseDirectory on Unix consistent with Windows
comment:
  On Unix, when you first hit Enter or click OK in the 
  tk_chooseDirectory dialog, either of the following 
  happens:
  - If the name that is entered in the "Selection" entry 
  is a valid directory, the dialog browses to that 
  directory.
  - If the name is not a valid directory, nothing 
  happens.

  Only when you hit Enter or click OK a second time does 
  the dialog return.

  This is inconsistent with the behavior of 
  tk_chooseDirectory on Windows, where hitting Enter or 
  clicking OK once ALWAYS completes the dialog.

  Also, especially the second case above is confusing, 
  where you click OK and nothing happens.

  The attached patch makes the behavior of 
  tk_chooseDirectory on Linux consistent with the 
  behavior on Windows.


tkt_uuid: 220780ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 7 High
foundin: obsolete: 8.0.3
resolution: Fixed
title: text tag bindings trigger on widget borders
comment:
  OriginalBugID: 949 Bug
  Version: 8.0.3
  SubmitDate: '1998-12-14'
  LastModified: '2000-01-19'
  Severity: LOW
  Status: Assigned
  Submitter: pat
  ChangedBy: hobbs
  OS: All


  Name:
  Greg McFarlane

  ReproducibleScript:
  # Run the script below and then move the
  mouse into the top border.

  % wish8.0
  text .t -width 30 -height 4 -relief sunken -borderwidth 10
  pack .t

  .t insert end " Tag here " TAG " no tag here"
  .t tag configure TAG -borderwidth 2 -relief raised
  .t tag bind TAG <Enter> {puts Enter}
  .t tag bind TAG <Leave> {puts Leave}

  ObservedBehavior:
  If <Enter> or <Leave> bindings are set on a text tag which at the very top left of a text widget, then the bindings are triggered when the mouse enters and leaves the top border.  Similar behaviour can be observed when the tag is at the bottom right of the text window - in this case the bindings are triggered when the mouse enters the bottom border.  Similarly when entering the highlight border.

  DesiredBehavior:
  I expect the bindings to only trigger when the mouse enters the tagged text, not when it enters the widget borders.



  Verified in 8.3b2 on WindowsNT. 
  -- 01/19/2000 hobbs


tkt_uuid: 2824916fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 05. Canvas Items
priority: 3 Low
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: again underline with rotated text
comment:
  This is a continuation of #2356057 after the bug mentioned there was indeed
  fixed.  The underline bar now looks almost like a bar.  But especially at certain
  angles, the bar looks rather like a part of a wedge, as visible with the example
  from  #2356057  after changing the values in one line to:
     set tm 5000; set d 45

  Strangely, the effect becomes *more* obvious, if the text of the item is also changed
  to e.g. three o's (rather than "foo").  Why does the shape of the bar depend also on other
  characters than the one it's under?

  PS: This is on Linux/X11, in case it matters.


tkt_uuid: 220581ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 2
foundin: obsolete: 8.1
resolution: Fixed
title: .text dump counts by bytes, not chars
comment:
  OriginalBugID: 2582 Bug
  Version: 8.1
  SubmitDate: '1999-08-19'
  LastModified: '2000-02-03'
  Severity: SER
  Status: Released
  Submitter: hobbs
  ChangedBy: ericm
  RelatedBugIDs: 2708 4043
  OS: All
  FixedDate: '2000-02-03'
  FixedInVersion: 8.3


  In the code snippet:

  % .text insert 1.0 \xb1\xb1\xb1
  % .text dump -all 1.0 2.0
  text ±±± 1.0 text {
  } 1.6

  We see that the text widget is counting in bytes, not chars,
  when it comes to Unicode stuff.  This might also affect
  other areas of text widget indexing (search, index, ...),
  where indices are required or returned.

  The problem is in tkText.c:DumpLine, where the function is iterating from the 0'th byte to the end byte of the line, printing out each tkText segment as it goes.  It uses a dumb helper function to format the output, and it gives the offsets to that function in bytes.  The helper doesn't have enough information to be able to fix the offset, so it must be done in DumpLine.  It's probably easiest to continue to use bytes as the iterator and just munge the value before printing it.

  - eric

  -- 02/02/2000 ericm

  OK, the actual fix was a little different than I expected.  I modified the helper function to take the index offsets in a slightly different form (a TkTextIndex structure instead of two integer offsets), and I modified DumpLine to conform to this new spec.  The helper function then has enough information to use TkTextPrintIndex to format the index into a readable value.  This fix is in 8.3 final.

  - eric

  -- 02/03/2000 ericm


tkt_uuid: 918052ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 31. Cursor Names
priority: 5 Medium
foundin: obsolete: 8.4.4
resolution: None
title: Memory leak connected to X11, Tk and an XCursor theme
comment:
  I'm experiencing memory leaks in Tk-based applications 
  (such as demos/widget) running under X11 on SuSE 
  Linux 9, XFree86-4.3.0.1-46 and tk-8.4.4-57. I 
  discovered it only exhibits in connection with a XCursor 
  theme installed in .icons, but apparently not necessarily 
  with an arbitrary theme. So far I noticed the problem 
  only in connection with a theme called Siver, which can 
  be found at 
  http://www.kde-look.org/content/show.php?content=5533 
   
  The leak appers in the X process, not the Tk applications 
  themselves but other toolkits, like Gtk or Qt are not 
  affected by this. To reproduce it, install the Silver 
  XCursor theme and do the following: 
   
  1) run widget demo: /usr/lib/tk8.4/demos/widget  
   
  2) run top and press M to sort processes by memory 
  usage 
   
  3) move mouse pointer over links in the widget main 
  window for a while 
  (may take some time for the first time, but generally not 
  longer than 
  a minute - the loger ) 
   
  4) watch the X process memory in top. On my setup it 
  grows by about 
  1MB/5 sec. 
   
  Petr 


tkt_uuid: 949792ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 21. [panedwindow]
priority: 5 Medium
foundin: None
resolution: Fixed
title: panedwindow closing error
comment:
  When panedwindow is closed when cursor is over sash,
  error "bad window path name" is generated. It is caused
  by Cursor procedure from panedwindow.tcl. The reason:
  winfo command is invoked after window was destroyed,
  when Cursor is re-scheduled with "after 150" command
  from itself.


tkt_uuid: 220665ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 15. [scale]
priority: 2
foundin: obsolete: 8.3b2
resolution: Fixed
title: bad scale RoundToResolution numerics
comment:
  OriginalBugID: 4099 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-27'
  LastModified: '2000-01-29'
  Severity: MED
  Status: Released
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3689
  OS: All
  FixedDate: '2000-01-29'


  Name:

  Don Porter



  Comments:

  In floating point arithmetic, it may not be true that

      

      (N + 1) * delta == N * delta + delta



  ReproducibleScript:

  # FILE demo.tcl

  pack [scale .s -length 441 -orient horizontal -resolution 0.5050838956 \

  -from 463.667016161 -to 563.67362749 -digits 18]

  .s set 513.7



  ObservedBehavior:

  $ wish demo.tcl



  Wave the mouse over the scale and watch the

  value and the slider "shake".



  DesiredBehavior:

  Scale should hold its value.



  Patch:

  Index: generic/tkScale.c

  ===================================================================

  RCS file: /cvsroot/tk/generic/tkScale.c,v

  retrieving revision 1.10

  diff -c -r1.10 tkScale.c

  *** tkScale.c   1999/12/22 20:01:07     1.10

  --- tkScale.c   2000/01/27 22:41:38

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

  *** 1147,1166 ****

        TkScale *scalePtr;                /* Information about scale widget. */

        double value;             /* Value to round. */

    {

  !     double rem, new;

    

        if (scalePtr->resolution <= 0) {

          return value;

        }

  !     new = scalePtr->resolution * floor(value/scalePtr->resolution);

        rem = value - new;

        if (rem < 0) {

          if (rem <= -scalePtr->resolution/2) {

  !           new -= scalePtr->resolution;

          }

        } else {

          if (rem >= scalePtr->resolution/2) {

  !           new += scalePtr->resolution;

          }

        }

        return new;

  --- 1147,1167 ----

        TkScale *scalePtr;                /* Information about scale widget. */

        double value;             /* Value to round. */

    {

  !     double rem, new, tick;

    

        if (scalePtr->resolution <= 0) {

          return value;

        }

  !     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;

          }

        }

        return new;



  PatchFiles:

  generic/tkScale.c





  Patch added to 8.3.0, also fixed resolution rounding bug in 3689. 
  -- 01/29/2000 hobbs


tkt_uuid: 552515ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 5 Medium
foundin: None
resolution: Fixed
title: Diff. bg color of canvas showing icons
comment:
  The icons in tk_messageBox are shown
  using a canvas. This canvas can have 
  different colour that the rest of the window,
  resulting in a strange appearence.
  Attached is a small patch that tries
  to fix this...


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

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

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


tkt_uuid: 2472990fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 41. Photo Images
priority: 5 Medium
foundin: obsolete: 8.6b1
resolution: None
title: PNG: format handler doesn't do -gamma
comment:
  TIP#244 specifies that the PNG loader should handle a user-specified -gamma option in conjunction with the gAMA chunk. Currently this is not done. To fix.


tkt_uuid: 220219ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: None
priority: 1 Zero
foundin: final: 8.1.1
resolution: Invalid
title: Try to compile expect-5.28 with tcl/tk8.1.1 on Sun SparcStation Solaris 2.2.x with failure.
comment:
  OriginalBugID: 2497 Bug
  Version: 8.1.1
  SubmitDate: '1999-08-04'
  LastModified: '1999-08-04'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: foster
  OS: Solaris
  Machine: Other
  ClosedDate: '1999-08-04'


  Name:
  Yi Luo



  (Per Scott R. reply to originator on 8/4/99)

  Expect 5.28 does not support Tcl/Tk 8.1.

  Instead, you need Expect 5.31 and Tcl/Tk 8.2b1+.  There were
  changes required to both Expect and Tcl/Tk in order to get
  the two to work properly.  You can download Tcl/Tk 8.2b1 from
  our website and get Expect from our CVS repository.

  http://www.scriptics.com
   
  -- 08/04/1999 foster


tkt_uuid: 220272ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 63. Tk_Win Functions
priority: 1 Zero
foundin: obsolete: 8.3b2
resolution: Invalid
title: button widget error occur
comment:
  OriginalBugID: 4068 Bug
  Version: 8.3b2
  SubmitDate: '2000-01-24'
  LastModified: '2000-01-25'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Windows 95
  OSVersion: WindowsNT4.0SP6a and Windows95
  Machine: PC
  ClosedDate: '2000-01-25'


  Name:
  Satoshi Imai

  Extensions:
  none

  ReproducibleScript:
  # Error occur by following script, if you focus in the button.
  # It's not joke.

  button .b -text Push
  pack .b

  ObservedBehavior:
  Error: unknown option "-state"



  Is this when the script is run interactively, or by double-clicking
  on it?  If the latter, what is the name of the script?

  This sounds like the error that pops up when someone has named a
  script after a class name for one of the widgets.  This is a known
  problem, because the class of the application becomes that for a
  widget, thus assuming the class bindings (like for <Enter>) as well.

  Need more info/verification from the user. 
  -- 01/25/2000 hobbs


tkt_uuid: 604004ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.0
resolution: None
title: unixWm-51.7 fails
comment:
  On Solaris 8 with CDE:

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

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

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

  Perhaps a consequence of TIP 107?


tkt_uuid: 706411ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 53. [selection]
priority: 7 High
foundin: obsolete: 8.4.2
resolution: Works For Me
title: text selection in a text widget significantly slower
comment:
  Tk applications which make use of text in text widgets
  are exhibiting significant slowdown in the text
  selection action under 8.4.2 as compared to 8.3.

  Behavior is being reported in cases where the
  application runs on solaris and displays on either
  solaris or back to a Windows machine (XP in at least
  one report) via Exceed's X software.

  The simplest example can be seen by:
    text .t
     pack .t

     Then typed some text into the widget and did a
  Button-1 drag
  selection with the mouse.  Wish 8.3 was as fast as ever in
  forming/altering the selection, with a speed comparable
  to highlighting
  text in MDE or an xterm.  But with 8.4, dragging the
  cursor alters the
  selection at a rate of about 1 character per second,
  which is incredibly
  slow. 


tkt_uuid: 987169ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 38. [tk_messageBox]
priority: 9 Immediate
foundin: obsolete: 8.5a1
resolution: Fixed
title: missing <Destroy> binding
comment:
  Situation: 
   
  wish 
  % toplevel .t 
  tk_messageBox -parent .t 
   
  -> now press on the close button of ".t" 
   
  -> ".t" will be destroyed and messageBox 
  of course too, since it is a descendant of ".t" 
   
  -> the wish will now block indefinatly in the 
  "vwait ::tk::Priv(button)" of the (now vanished) 
  messageBox. 
   
  I think you should consider to incluse a binding  
  on the <Destroy> event somewhere in msgbox.tcl 
  script. 
   
  For example like this (after # 6.): 
   
   
  bind $w <Destroy> "if {!\[info exists 
  ::tk::Priv(button)\]} { 
      [$w.$data(-default) cget -command] 
      }" 
   
   
  This set the variable (vwait waits for) with whatever 
  was configured to be the default.  
   
  Note: You have additionally to make shure, that 
  the variable is unset one you invoke the messageBox. 
   
  I changed therefore (after # 1.): 
      catch {destroy $w} 
   
  into: 
   
      destroy $w 
      unset -nocomplain ::tk::Priv(button) 
   
  The catch is not needed anymore. 
   
   
  Note also: 
   
  To make the whole thing reentrant, you should 
  rename this variable info something, that includes 
  the widgetname like ::tk::Priv($w,button) 
   
   


tkt_uuid: 220448ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 2
foundin: obsolete: 8.1b1
resolution: Fixed
title: Tear-off menus don't respect vertical task bar
comment:
  OriginalBugID: 1465 Bug
  Version: 8.1b1
  SubmitDate: '1999-03-08'
  LastModified: '2000-01-07'
  Severity: SER
  Status: Released
  Submitter: pat
  ChangedBy: hobbs
  OS: Windows 98
  Machine: X86
  FixedDate: '2000-01-07'
  FixedInVersion: 8.3b1


  Name: Christopher Nelson

  ObservedBehavior:
      When working with a task bar down the left side of the screen, tear-off
      menus appear at (0,0), under the task bar and out of sight. A button
      appears on the task bar corresponding to the tear-off but clicking it
      does not bring the tear-off to the top.

  DesiredBehavior:
      The tear-off should not always appear at (0,0) but should at least not
      appear under the task bar.


  With 8.3b1, verified that while they still appear at 0,0 all the
  time, with the task bar on the left side, the 0,0 start justs to
  the right of the task bar, so the menu won't be obscured.  This
  was with NTsp4. 
  -- 01/07/2000 hobbs


tkt_uuid: 879175ffffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 66. Aqua Window Operations
priority: 5 Medium
foundin: None
resolution: Fixed
title: Windows in front of all on Mac OS X
comment:
  I wish we can have a feature on Mac OS X to specify a 
  window to appeared "in front of all" windows of any app on 
  Mac OS X. Like a notify window or something like that.


tkt_uuid: 1561020fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 46. Unix Fonts
priority: 7 High
foundin: obsolete: 8.4.13
resolution: None
title: devanagari fonts rendering in python-Tkinter
comment:
   devanagari fonts rendering in python-Tkinter  
  Private: (?)
  No
  My email address is siva@mail.cern.ch

  Hi,

  I hope a tkinter question can be addressed here as well.

  I am trying to display Devanagari unicode fonts in a
  tkinter label/text
  widget.

  To make new characters, the unicode fonts provide this
  functionality of
  using combination of unicode codes to make a single new
  character. Like
  for instance the kSa in unicode is
  u'\u0915\u094D\u0937'. In Linux, this
  looks perfect in a web-browser or in my shell-konsole
  which supports
  unicode.
  I am using Python-2.4.2 which definitely supports
  unicode. But the
  problem is in the final visual rendering that it does
  not show the kSa
  character but shows it as k Sa as two separate
  characters. For example,
  u'\u0915\u093f'. u0915 stands for 'ka' the first
  consonant in devanagari.
  u093f stands for the third vowel 'i' pronounced as 'e'
  as in 'pre'. This
  vowel when combined to 'ka' must have a line+curve that
  visually looks
  like 'f' should be to the left of the consonant 'ka'.
  Though in windows,
  when I give u'\u0915\u093f', it renders correctly, in
  redhat linux, it shows the 'f' to the right which makes
  it look like it is adding the
  vowel to the next consonant in a word. Now there is
  also this another
  problem but both in windows and linux alike. The
  making of new
  characters like the kSa or using the Zero-Width-Joiner and
  Zero-Width-Non-Joiner to make half characters etc....

  Is there by any chance these things could be correctly
  rendered?? I mean,
  I use PyQt, it correctly renders the fonts. But, PyQt
  needs Qt and
  getting Qt for Windows is a whole big story. So, I
  want to stick to
  Tkinter and try. Can you please suggest any method
  that would allow me
  to make the Tkinter-Python to give the correct visual
  rendering of the
  characters. We use the X11 fonts while running PyQt
  which I guess the Qt
  uses. If my xterm shell-konsole could render unicode
  fonts correctly, I
  would guess Python Tkinter as a GUI package must
  definitely be able to
  render the fonts correctly.

  please let me know if you can help me, if yes, then how??

  Thanks in advance!!

  Cheers,
  -Siva.
  One more comment I need to add is the reply I got from the
  Python help group.  They mentioned that, it is because of
  the limitation of the Tcl/Tk and asked me to contact the
  Tcl/Tk help group.  That is why I am here.  Can you please
  suggest, if Tcl/Tk current or next version will support
  this
  kind of unicode rendering??  Or can you suggest some very
  simple thing that I could change to get this working like a
  iso10646-1.enc file??


tkt_uuid: 3603738fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 11. Aqua Menus
priority: 5 Medium
foundin: current: 8.6.0
resolution: None
title: menus can't post if application is not in foreground
comment:
  A popup menu causes an error if you try to post it while another application is in the foreground.

  test code:
  menu .pm 
  .pm add command -label test
  bind . <Button-2> "tk_popup .pm %X %Y"

  works fine if Wish is in the foreground.
  If you click on any other application, then right-click on the Wish window (while leaving it in the background) an error is thrown on the .pm post command.


tkt_uuid: 1445404fffffffffffffffffffffffffffffffff
type: Patch
status: Closed
subsystem: 81. Portability
priority: 9 Immediate
foundin: None
resolution: Accepted
title: Header file cleanups
comment:
  In keeping with the convention that standard header
  files can be assumed present and "../compat" versions
  should only be used if selected with an explicit -D
  flag (computed at configure-time), the attached patch
  switches  the logic for stdlib.h to use the ../compat
  versions  only if -DNO_STDLIB_H is specified instead of
  if -DHAVE_STDLIB_H is missing.  Similarly for unistd.h
  in the unix and osx portability headers.

  This was done for Tcl a while ago, the patch below just
  does the same for Tk (8.4 branch, to be forward-ported
  later).

  Also removes the explicit declaration 'extern int
  errno;' from tkUnixPort.h and tkMacOSXPort.h; for one,
  this is not legal in standard C, and besides that no
  files in the Tk source base actually refer to 'errno'.

  tkMacOSXPort.h can use some further cleanup -- since
  it's a known platform, many of the #ifdef tests aren't
  needed at all (e.g., OSX has <unistd.h>, so there's no
  need to test for -DNO_UNISTD_H).  Haven't done that yet.


tkt_uuid: 746267ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 55. [focus]
priority: 4
foundin: None
resolution: Duplicate
title: Possible focus bug in Aqua Tk 8.4.2
comment:
  There is an apparent focus bug in Aqua Tk 8.4.2 running on MacOS X 10.2.6.

  - Run the following code (which started as a pop-up help system
    but has been stripped down to just show the bug).
  - Click on the entry widget, so it received focus
  - Move the mouse a bit within the entry widget,
    so the pop-up help window is displayed.
    (Make sure the mouse is not over where the help window
    pops up else it will go away instantly.)
  - Type one or more characters.
  - On MacOS X the code *claims* that the entry widget .e still has focus
    but this is a lie. Keystrokes are actually ignored,
    and it seems likely they are going to the pop-up help window
    instead of the entry widget that allegedly still has focus.

  Notes:
  - Adding code that tells Tk to return the focus to the entry
    does not help. One still cannot type in the entry widget.
    Maybe this is not surprising, since tcl/tk seems to think
    the entry widget already has focus.
  - The code runs fine under my unix setup:
    (unix Tcl/Tk 8.4.1, MacOS X 10.2.6, Apple's X11 beta 3),
    BUT it starts failing in a similar way if I remove the
    "wm overrideredirect" command.
  - Thus perhaps the bug is more pervasive than MacOS,
    and/or it's not a bug and I'm going about this all wrong.
   

  entry .e
  pack .e

  bind .e "<Motion>" {
  destroy .t
  puts "show help; focus is [focus]"
  toplevel .t
  wm overrideredirect .t 1
  wm transient .
  message .t.m -text "this is a help msg"
  pack .t.m
  puts "help is showing; focus is [focus]"
  }

  bind .e "<Leave>" {
  puts "leave"
  destroy .t
  }

  bind .e "<KeyPress>" {
  puts "keypress"
  destroy .t
  }


tkt_uuid: 1289565fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 70. Event Loop
priority: 8
foundin: obsolete: 8.4.11
resolution: Fixed
title: 8.4 ClientMessage handler breaks GenericHandlers
comment:
  8.4 has a bug that was fixed in 8.5 some time ago,
  involving the list management for ClientMessage
  handlers.  The client message handlers can corrupt the
  generic handler list.

  In the ClientMessage handler that invokes the callbacks
  8.4 is using:
  tsdPtr->lastGenericPtr = genPrevPtr;
  it should be:
  tsdPtr->lastCmPtr = getPrevPtr;

  I brought this up some time ago, in the thread about
  the patch I wrote to cleanup the tkEvent.c mess.  It
  seems that Jeff Hobbs lost track of it (perhaps it
  shouldn't have been assigned to him?).

  This effects anything using GenericHandlers, such as
  window managers.


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

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

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

  Thanks Joe!


tkt_uuid: 2604420fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 88. Themed Tk
priority: 6
foundin: obsolete: 8.5.6
resolution: Fixed
title: text lost (?) in ttk_intro manpage
comment:
  The text in the OVERVIEW section of the ttk_intro(n) manpage is cut off in the middle of a sentence.
  (Not fixed in current CVS; same with online html version.)


tkt_uuid: 1220692fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 70. Event Loop
priority: 5 Medium
foundin: None
resolution: None
title: tk locks up
comment:
  This script, when run under strace, locks up Tk on Linux:

  # loop.tcl

  # Run like so:
  # strace tclsh loop.tcl
  package require Tk

  proc screenupdate {num} {
      incr num
      .foo configure -text $num
      after 10 [list screenupdate $num]
  }

  button .foo
  pack .foo

  screenupdate 0
  -----

  Or better, it seems to reproduce the bug I see in a
  script that locks up even without strace.

  The following script will lock it up without strace. 
  Ok - so it's kind of evil, but still, it seems to be
  tickling a race condition or something.  Note that it's
  not just slow - it's locked, it's not doing anything.

  # loop.tcl

  # Run like so:
  # strace tclsh loop.tcl
  package require Tk

  proc afterburner {} {
      after 10 afterburner
  }


  proc screenupdate {num} {
      incr num
      .foo configure -text $num
      after 10 [list screenupdate $num]
  }

  button .foo
  pack .foo

  screenupdate 0

  afterburner
  afterburner
  afterburner

  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner

  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner

  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner
  afterburner



  -------------


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

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

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

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

  Thanks, Steven Atkinson, stevenaaus yahoo.com


tkt_uuid: 2759119fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 9 Immediate
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: failed conversions to [tailcall] use
comment:
  Last two commits to tk.tcl broke the HEAD.

  Example test failure:

  ==== filebox-3.5-0 tk_getOpenFile command FAILED
  ==== Contents of test case:

              catch {unset tv}
              catch {unset typeName}
              ToPressButton $parent ok
              if {[info exists tv]} {
              } else {
              }
              set choice [tk_getOpenFile -title "Press Ok"  -filetypes $filters($x) -parent $parent  -initialfile $fileName -initialdir $fileDir  -typevariable tv]
              if {[info exists tv]} {
                  regexp {^(.*) \(.*\)$} $tv dummy typeName
              } else {
                  set typeName "-unset-"
              }
              set typeName

  ---- Test generated error; Return code was: 1
  ---- Return code should have been one of: 0 2
  ---- errorInfo: bad level "2"
      while executing
  "uplevel 2 [list info exists $data(-typevariable)]"
      (procedure "::tk::dialog::file::" line 75)
      invoked from within
  "::tk::dialog::file:: open -title {Press Ok} -filetypes {
          {"Text files"           {.txt .doc}     }
          {"Text files"           {}              TEXT}
          {"Tcl Scripts"          {.tcl}          TEXT}
          {"C S..."
      invoked from within
  "tk_getOpenFile -title "Press Ok"  -filetypes $filters($x) -parent $parent  -initialfile $fileName -initialdir $fileDir  -typevariable tv"
      ("uplevel" body line 8)
      invoked from within
  "uplevel 1 $script"
  ---- errorCode: TCL VALUE LEVEL
  ==== filebox-3.5-0 FAILED


  Appears that conversions of

      return [foo]

  to

      tailcall foo

  failed to account for hardcoded level values
  in [up*] commands in "foo".

  FWIW, I think this is a demonstration that
  any values besides #0, 0, or 1 for the level
  argument to [up*] are just bugs waiting
  to happen.


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

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


tkt_uuid: 2763385fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 18. [text]
priority: 5 Medium
foundin: obsolete: 8.5.6
resolution: Invalid
title: segmentation fault in DisplayText
comment:
  Hi,
  this is a weird Tk bug that I'm experiencing with tcl/tk 8.5.6. I don't know exactly how to reproduce, I'm testing video conferencing in aMSN and I keep getting this when I click on the call button (happens maybe once per 15 tries). 
  I have the core file saved on my disk, you can ping me over IRC (KaKaRoTo) if you need it.. I don't want to attach it, it's 175MB...
  It looks like DisplayText is called with some invalid data on the "update idletasks"...
  Here's the bt: 
  #0  0xb7fef975 in DisplayText (clientData=0xbf49ab0) at /home/kakaroto/coding/tk8.5-8.5.6/unix/../generic/tkTextDisp.c:4020
  4020                if ((dlPtr2->flags & OLD_Y_INVALID)
  (gdb) bt full
  #0  0xb7fef975 in DisplayText (clientData=0xbf49ab0) at /home/kakaroto/coding/tk8.5-8.5.6/unix/../generic/tkTextDisp.c:4020
          dlPtr2 = (DLine *) 0x30207473
          y = 1769349359
          oldY = 211
          offset = 973519755
          height = 1634872696
          damageRgn = (TkRegion) 0xb48e44e8
          textPtr = (TkText *) 0xbf49ab0
          dInfoPtr = (TextDInfo *) 0xc018d88
          dlPtr = (DLine *) 0xb4cb90ef
          prevPtr = (DLine *) 0x0
          pixmap = 3086096392
          maxHeight = -1078323096
          borders = -1208870904
          bottomY = 0
          interp = (Tcl_Interp *) 0xbf31180
  #1  0xb7eed398 in TclServiceIdle () from /usr/lib/libtcl8.5.so.0
  No symbol table info available.
  #2  0xb7ecea81 in Tcl_DoOneEvent () from /usr/lib/libtcl8.5.so.0
  No symbol table info available.
  #3  0xb7f4e436 in Tk_UpdateObjCmd (clientData=0x9903d00, interp=0x98dd7c0, objc=2, objv=0x9a3b834) at /home/kakaroto/coding/tk8.5-8.5.6/unix/../generic/tkCmds.c:1108
          flags = 32
          index = 0
          dispPtr = (TkDisplay *) 0x9a3b790
          updateOptions = {0xb80468b5 "idletasks", 0x0}
  #4  0xb7e4d881 in ?? () from /usr/lib/libtcl8.5.so.0



  I also had another similar one (but I lost the core file, sorry), here's its stack trace :
  Program terminated with signal 11, Segmentation fault.
  #0  0xb7f198ce in DisplayText (clientData=0xc2cd830) at /home/kakaroto/coding/tk8.5-8.5.6/unix/../generic/tkTextDisp.c:4001
  4001            if ((dlPtr->flags & OLD_Y_INVALID)
  (gdb) bt full
  #0  0xb7f198ce in DisplayText (clientData=0xc2cd830) at /home/kakaroto/coding/tk8.5-8.5.6/unix/../generic/tkTextDisp.c:4001
          dlPtr2 = (DLine *) 0x0
          y = 1
          oldY = 211
          offset = -210
          height = 135
          damageRgn = (TkRegion) 0xb23b8f30
          textPtr = (TkText *) 0xc2cd830
          dInfoPtr = (TextDInfo *) 0xc37e5c8
          dlPtr = (DLine *) 0x2030ef00
          prevPtr = (DLine *) 0x0
          pixmap = 65036849
          maxHeight = 18
          borders = -1209747448
          bottomY = 0
          interp = (Tcl_Interp *) 0xc156c40
  #1  0xb7e17398 in TclServiceIdle () from /usr/lib/libtcl8.5.so.0
  No symbol table info available.
  #2  0xb7df8a81 in Tcl_DoOneEvent () from /usr/lib/libtcl8.5.so.0
  No symbol table info available.
  #3  0xb7e78436 in Tk_UpdateObjCmd (clientData=0x9c78d00, interp=0x9c527c0, objc=2, objv=0x9db0644) at /home/kakaroto/coding/tk8.5-8.5.6/unix/../generic/tkCmds.c:1108
          flags = 32
          index = 0
          dispPtr = (TkDisplay *) 0x9db05a0
          updateOptions = {0xb7f708b5 "idletasks", 0x0}


tkt_uuid: 3515522fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 13. Win Menus
priority: 5 Medium
foundin: None
resolution: None
title: Crash when adding system menu to undocked window
comment:
  I have recreated this in a fresh pull from fossil core-8-5-branch yesterday. On a windows build, undocking a window, adding a system menu, and then redocking the window will cause a crash when the menubar is destroyed.

  Here is a testcase:
  toplevel .w
  menu .m
  .w configure -menu .m
  menu .m.system
  .m.system add command -label "sys test"
  .m add cascade -label System -menu .m.system
  wm forget .w
  destroy .w

  Few more details:
  The equivalent in tcl8.4 (replacing wm forget .w w/ wm toplevel .w 0) works fine.
  The crash occurs in TkWinGetWrapperWindow when a null wmInfoPtr is dereferenced.
  I can avoid the crash by re-adding the call to TkFrameReleaseMenu in WmForgetCmd which didn't seem to make the move when WmToplevelCmd became WmForgetCmd, however i don't know if this is the proper solution.


tkt_uuid: 1634958fffffffffffffffffffffffffffffffff
type: RFE
status: Closed
subsystem: 05. Canvas Items
priority: 5 Medium
foundin: None
resolution: None
title: Add cubic bezier curves to canvas primitives
comment:
  Currently there is no easy way to draw cubic bezier splines on Tk canvas (having two different control points for each segment).
  Smoothing lines or polygons of course does not give it - it gives only quadratic bezier splines.
  Cubic splines are the Postscript drawing primitives not supported by Tk canvas. 
  It would be very useful for creating applications operating on vector graphics.


tkt_uuid: 220032ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 1 Zero
foundin: final: 8.0.5
resolution: Duplicate
title: Tk crashes on exit when menus are deleted/recreated
comment:
  OriginalBugID: 3237 Bug
  Version: 8.0.5
  SubmitDate: '1999-10-28'
  LastModified: '1999-10-29'
  Severity: CRIT
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  RelatedBugIDs: 3236
  OS: Windows NT
  Machine: X86
  ClosedDate: '1999-10-29'


  Name:
  Sammy Nachimuthu

  CVS:
  RCS: @(#) $Id: tkConfig.c,v 1.2 1998/09/14 18:23:08 stanton Exp $

  CustomShell:
  Refer to section 9.

  Comments:
  The fix only removes the NULL crash. It is better to fix the place where
      the NULL pointer is generated.

  ReproducibleScript:
  When the menu entries which has sub-menus are deleted and recreated on
      the same name, the TK crashes on exit.

  ObservedBehavior:
  The error message says: "The instruction at "0x0045bda" referenced
      memory at "0x00000000". The memory could not be "read"". When I ran with
      the tk8.0.5 debug version of the source code, the error was located in
      the following location of DoConfig function in tkConfig.c file.

      if ((*value == 0) && (specPtr->specFlags & TK_CONFIG_NULL_OK)) {
      nullValue = 1;
          }

  DesiredBehavior:
  Fix the error where the NULL value is created.

  Patch:
  The following fix in DoConfig function of tkConfig.c removed the NULL pointer crash.

      if ((value == NULL) && (specPtr->specFlags & TK_CONFIG_NULL_OK)) {
  nullValue = 1;
      } else if ((*value == 0) && (specPtr->specFlags & TK_CONFIG_NULL_OK)) {
  nullValue = 1;
      }

  PatchFiles:
  generic\tkConfig.c


tkt_uuid: 220220ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 10. Generic Menus
priority: 1 Zero
foundin: obsolete: 8.0.3
resolution: Invalid
title: Menus are detached from their parents
comment:
  OriginalBugID: 2509 Bug
  Version: 8.0.3
  SubmitDate: '1999-08-05'
  LastModified: '1999-08-20'
  Severity: MED
  Status: Closed
  Submitter: techsupp
  ChangedBy: hobbs
  OS: Solaris
  OSVersion: 2.5
  Machine: Other
  ClosedDate: '1999-08-20'


  Name:
  Steve Duncan

  CustomShell:
  No mods or redefined commands, as far as I am aware.

  Comments:
  The changes file suggests that this is a bug which has been fixed before
      in Tk.  I would guess that it has been reanimated by the menubar changes
      in 8.0.

  ReproducibleScript:
  Can't currently reproduce except in our application (which is large).

  ObservedBehavior:
  This is how it happens:
      
      1. I select a menu option in a launcher appliction that launches a new
      application with its own toplevel window.
      2. While waiting for the new app to initialise, I click on a menu item
      in the launcher toplevel window and hold the mouse button down.  The
      launcher window is inactive at this time so the menu is not posted.
      3. I release the mouse button once the new toplevel window has been
      mapped. The launcher window no longer has the focus, but releasing the
      mouse button causes the menu to pop up.
      4. This is the nasty part:  The menu is no longer bound to the menubar.
      It stays where it was first posted on the display

  DesiredBehavior:
  I don't expect the menu to pop up when the mouse button is released in
      the first place. I certainly don't expect the menu to come unstuck from
      the menu bar.



  This can be classified as 'quirk', and is not exclusive to Tk.
  I am fairly certain what is happening here is that the process
  is busy launching the new toplevel, but X has queued the event
  for you wanting to post a menu.  You will have moved off the
  launcher before Tk gets around to processing the message it
  received from X, but it will process it.

  You can get this menu to go away by rerequesting a menu popup.
  You may be able to avoid the problem entirely by rearchitecting
  to add a few update idles in the toplevel launching code, or
  exec it as a process in the background. 
  -- 08/20/1999 hobbs


tkt_uuid: 3019363fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 88. Themed Tk
priority: 5 Medium
foundin: obsolete: 8.6b1.1
resolution: Fixed
title: `make genstubs` failure
comment:
  $ make genstubs
  /usr/bin/tclsh8.4 /home/dgp/cvs/tcl-only/tools/genStubs.tcl /home/dgp/cvs/tk/unix/../generic \
                  /home/dgp/cvs/tk/unix/../generic/tk.decls /home/dgp/cvs/tk/unix/../generic/tkInt.decls
  Emitting tk
  Emitting tkInt
  Emitting tkIntPlat
  Emitting tkIntXlib
  Emitting tkPlat
  /usr/bin/tclsh8.4 /home/dgp/cvs/tk/unix/../generic/ttk/ttkGenStubs.tcl /home/dgp/cvs/tk/unix/../generic/ttk /home/dgp/cvs/tk/unix/../generic/ttk/ttk.decls
  Emitting ttk
  syntax error in expression "$name in $hooks($intf)": extra tokens at end of expression
      ("if" test expression)
      while compiling
  "if {$name in $hooks($intf)} {
  ...


  The tool script tk/generic/ttk/ttkGenStubs.tcl uses the
  "in" operator, a feature of Tcl 8.5 and later.  The script
  needs a [package require Tcl 8.5].

  Once that is in place the failure will be a  bit tidier, but
  the remaining failure is that if the tool scripts used
  in developing Tk need Tcl 8.5, then the Makefile definitions
  for the rules -- and the configure machinery that sets up
  all the pieces of those definitions --  need to make sure
  those needs are met.

  Either the TCL_EXE should be required to be a Tcl
  shell executable of at least version 8.5, and the
  machinery to set that value should enforce that,
  or we need another Makefile variable to hold a
  different executable which meets that requirement
  and then revise the "genstubs" target to make use
  of it.


tkt_uuid: 1576583fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 41. Photo Images
priority: 8
foundin: obsolete: 8.5.1
resolution: Out of Date
title: Crash displaying large images
comment:
  I have a series of gif files of dimensions of the order
  of 4500 x 4500 pixels, which I am trying to display
  using a Tk canvas.  Some do, some don't.  On Windows,
  those that don't, crash with the panic error message
  Fail to create pixmap with Tk_GetPixMap in
  ImgPhotoInstanceSetSize.  On MacOS X, those that don't,
  are simply blank.  The following short script
  reproduces the problem by creating a similarly large
  image on-the-fly, without the hassle of uploading a 2Mb
  file to SourceForge.  It fails at roughly the same
  dimensions.  It uses the ActiveTcl gif image of the
  earth seen from space.

  package require Tk
  canvas .c
  pack .c
  # Simple bindings to show extent of image by dragging
  bind .c <ButtonPress-1> {%W scan mark   %x %y}
  bind .c <B1-Motion>     {%W scan dragto %x %y 1}

  set i 2500
  set fname C:/Tcl8.4/demos/Tk8.4/images/earth.gif
  set img1 [image create photo -file $fname]
  set img2 [image create photo]
  label .l -textvariable i
  pack .l -side left
  button .b -text Bigger -command draw
  pack .b -side left

  proc draw {} {
      global i
      global img1
      global img2
      image delete $img2
      incr i 500
      set img2 [image create photo -width $i -height $i]
      $img2 copy $img1 -to 0 0 $i $i
      .c create image 0 0 -anchor nw -image $img2
  }

  draw


tkt_uuid: 657656ffffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 37. [tk_get*File]
priority: 7 High
foundin: None
resolution: Remind
title: -initialfile doesn't hilight filenames
comment:
  tk_getOpenFile -multiple 1 -initialfile [glob *.jpg]

  Lists all of the files in the 'filename' entry,
  however, they are not selected.  It would be nice to
  have the visual confirmation that the files are indeed
  the ones you want, and also "not breaking the metaphor"
  or some such.


tkt_uuid: 2282861fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 67. Unix Window Operations
priority: 5 Medium
foundin: obsolete: 8.4.19
resolution: Invalid
title: wm overrideredirect on suse11.0/KDE3.5 not working
comment:
  One additional detail (although it should have no effect on the problem): the ATI provided driver pack is installed over the one in the suse distribution (for the ATI Mobile X600 video card).

  The Windows counterpart does not have this problem.

  NJG (on the wiki)


tkt_uuid: 541999ffffffffffffffffffffffffffffffffff
type: Patch
status: Open
subsystem: 18. [text]
priority: 5 Medium
foundin: None
resolution: Fixed
title: long lines with -wrap none. fixes
comment:
  Long lines (eg 10,000 characters) that are displayed 
  with -wrap none demonstrate a variety of bugs.

  Firstly display is slow (more noticable with really 
  long lines) and secondly the tag colours, 3d bevels, 
  and the text itself is often displayed incorrectly.

  The source of all of these bugs is 16-bit limitations 
  in the coordinates for X11. The patch adds in a 
  variety of add-hoc manual clipping in order to keep 
  coordinates within the 16-bit space.

  Note that the same bugs also occur on windows due to 
  the 16-bit code in the xlib translation layer (eg 
  XSegment, XPoint and XRectangle structure 
  definitions). 

  This patch was implemented and tested with 8.3.1, but 
  the fix has been added into files checked out from 
  cvs HEAD today (10th April 2002), although they have 
  not been tested with that version. (I doubt there'll 
  be any difference as the files changed have not had 
  may edits.)


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

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

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

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

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


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


tkt_uuid: 612110ffffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 01. Bindings
priority: 9 Immediate
foundin: obsolete: 8.4.0
resolution: Fixed
title: Crash on FocusIn / FocusOut binding
comment:
  Jakub Travnik wrote:
  > Jakub Travnik wrote:
  >> P.S.: searching ruby-talk archive show that this bug
  has been noticed
  >> before but with no attempt to correct it. But since
  python can do it
  >> and ruby tcl/tk is modeled after python's so it
  should be fixable.
  >>
  > 
  > Hello,
  > 
  > I have solved the problem. Bug is in the Tk itself,
  see following
  > tcltk code:
  > ----cut_here-------------------
  > entry .e1 -width 10
  > entry .e2 -width 10
  > label .l1 -text "initial"
  > pack .e1 -side left
  > pack .e2 -side left
  > pack .l1 -side left
  > bind .e1 <FocusIn> {.l1 configure -text %S}
  > bind .e1 <FocusOut> {.l1 configure -text %S}
  > -------------------------------
  > 
  > This will crash in Tk_GetHWND called from
  TkpPrintWindowId
  > called from case "%S" in ExpandPercents when
  FocusIn/FocusOut event
  > happen.
  > 
  <snip>

  > 
  > Long term fix is to remove %S from tk.rb file
  depending on event, or
  > fix tcl/tk windows version to behave in correct way
  for this situation.
  > 
  I can confirm the crash with tcl/tk 8.4.0 from cvs.
  Windows 2000.

  Michael Schlenker

  callstack dump:
  Tk_GetHWND(unsigned long 3) line 147 + 3 bytes
  TkpPrintWindowId(char * 0x0012f800, unsigned long 3)
  line 174 + 15 bytes
  ExpandPercents(TkWindow * 0x00a23cc8, const char *
  0x00a1f06c, _XEvent * 
  0x00a7f798, unsigned long 0, Tcl_DString * 0x0012faa4)
  line 2576 + 19 bytes
  Tk_BindEvent(Tk_BindingTable_ * 0x008c4448, _XEvent *
  0x00a7f798, 
  Tk_Window_ * 0x00a23cc8, int 4, void * * 0x0012fbc0)
  line 1670 + 40 bytes
  TkBindEventProc(TkWindow * 0x00a23cc8, _XEvent *
  0x00a7f798) line 288 + 
  31 bytes
  Tk_HandleEvent(_XEvent * 0x00a7f798) line 1017 + 13 bytes
  WindowEventProc(Tcl_Event * 0x00a7f790, int -3) line
  1399 + 12 bytes
  Tcl_ServiceEvent(int -3) line 622 + 11 bytes
  Tcl_DoOneEvent(int -3) line 861 + 9 bytes
  Tk_MainLoop() line 1457 + 13 bytes
  Tk_MainEx(int 1, char * * 0x008626c8, int (Tcl_Interp
  *)* 0x00401005 
  _Tcl_AppInit, Tcl_Interp * 0x00864790) line 285
  WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ *
  0x00000000, char * 
  0x0013285d, int 10) line 140 + 26 bytes
  WinMainCRTStartup() line 330 + 54 bytes
  KERNEL32! 77e7d326()


tkt_uuid: 3083971fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 20. [tk_optionMenu]
priority: 5 Medium
foundin: obsolete: 8.5.7
resolution: Fixed
title: tk_optionMenu popup in wrong location on extended desktop
comment:
  I'm running ActiveTcl 8.5.7 on WinXP with an extended desktop. The main screen (the one with the taskbar) is to the right and somewhat lower than the secondary screen. When a tk_optionMenu is on the part of the secondary screen that's above the main screen, then the menu pops up too low... in fact, it's at the top edge of the main screen, as you can see in the attached screenshot. If the tk_optionMenu is below the top of the main screen (on either screen) then it pops up where expected.


tkt_uuid: 892194ffffffffffffffffffffffffffffffffff
type: Support
status: Closed
subsystem: None
priority: 6
foundin: None
title: TIP #222 - Windows toplevel transparency (-alpha) option
comment:
  The attached patch is a demo for Win2K/XP alpha
  transparency for entire toplevels.  While cool looking
  ... it's all relatively useless outside of demos and
  splash screens.  I attach it here for reference.  Made
  against win/tkWinWm.c of 8.5a0.


tkt_uuid: 1224330fffffffffffffffffffffffffffffffff
type: Bug
status: Closed
subsystem: 13. Win Menus
priority: 8
foundin: obsolete: 8.4.13
resolution: Fixed
title: Bug in menu delete
comment:
  The following code shows a bug in the windows menu 
  implementation:

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

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

  I submit this bug as a new one because I don't know 
  how to reopen bug 525111.

  This happens on Win XP SP2 with the ActiveState 
  binary distribution of Tcl/Tk 8.4.10.


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

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


tkt_uuid: 1424367fffffffffffffffffffffffffffffffff
type: Bug
status: Open
subsystem: 04. Canvas Basics
priority: 5 Medium
foundin: obsolete: 8.4.12
resolution: None
title: image item with activeimage and bind to destory - drag crash
comment:
  If you create an image item in a canvas that contains
  an activeimage, then you bind it so that it is
  destroyed when you click it. It is fine if you just
  click on it (it will be destroyed) but if you click and
  drag off it then it will cause a crash.

  Here is a very short test app that shows this note you
  need to have an image in the same folder, any image
  should do (either name it close.gif, or change the link
  in the code). If you click on the image it destroys it,
  if you click on the image and drag off it - crash:

  pack [canvas .c]
  set i [image create photo -file close.gif]
  .c create image 20 20 -anchor nw -image $i -activeimage
  $i -tag c1text
  .c bind c1text <ButtonRelease-1> "destroy .c"

  #note, you can get around the bug by replacing either
  (or both) of the last 2 lines with these:
  #.c create image 20 20 -anchor nw -image $i -tag c1text
  #.c bind c1text <ButtonRelease-1> "after 0 \"destroy .c\""


  Just to note I ran this under windows using the
  binaries from Activestate under Tcl/Tk 8.4.11, however
  I got a friend to test it under linux 8.4.11 and 8.4.12
  and he said that it causes a crash under both cause, he
  also was able to give me the callstack (not sure if it
  was for 8.4.11 or 8.4.12) although it is pretty
  intuitive what this crash is probably caused by...
  Program received signal SIGSEGV, Segmentation fault.
  0x005ba93c in Tk_CanvasEventuallyRedraw () from
  /usr/lib/libtk8.4.so
  (gdb) bt
  #0  0x005ba93c in Tk_CanvasEventuallyRedraw () from
  /usr/lib/libtk8.4.so
  #1  0x005bc860 in Tk_CreateItemType () from
  /usr/lib/libtk8.4.so
  #2  0x005bd06e in Tk_CreateItemType () from
  /usr/lib/libtk8.4.so
  #3  0x00581766 in Tk_HandleEvent () from
  /usr/lib/libtk8.4.so
  #4  0x00581c44 in Tk_HandleEvent () from
  /usr/lib/libtk8.4.so
  #5  0x001dc3f3 in Tcl_ServiceEvent () from
  /usr/lib/libtcl8.4.so
  #6  0x001dc68f in Tcl_DoOneEvent () from
  /usr/lib/libtcl8.4.so
  #7  0x00581088 in Tk_MainLoop () from /usr/lib/libtk8.4.so
  #8  0x0058e9f7 in Tk_MainEx () from /usr/lib/libtk8.4.so
  #9  0x080487e4 in main ()


