Tk Source Code

Wish 8.6.10 has a notebook/tab/panedwindow regression which i can't help with much because i don't deal with this stuff regularly.  ScidvsPC tabbed window moves (drag and drop) are throwing errors in 8.6.10. To reproduce, start scid, select Options->Windows->RestoreLayout->Custom, then drag the gamelist pane up to the PGN pane. 8.6.9 works fine.

Error is
---------
ambiguous compound "": must be none, text, image, center, top, bottom, left, or right
    (processing "-compound" option)
    invoked from within
".tb36 add .fdockglistWin -padding 0 -sticky nsew -state normal -text {Game List: [fics] 12173/12173 games} -image {} -compound {} -underline -1"
    ("eval" body line 1)
    invoked from within
"eval $dsttab add $f $o"

The 8.6.10 and 8.6.9 "puts" debugs are below.
I *think* the "compound" options returned by [$srctab tab TAB] are in a different form, which is throwing errors.
---------------------------------------------
8.6.10: eval .tb36 add .fdockglistWin -padding 0 -sticky nsew -state normal -text {Game List: [fics] 12173/12173 games} -image {} -compound {} -underline -1
8.6.9:   eval .tb36 add .fdockglistWin -padding 0 -sticky nsew -state normal -text {Game List: [fics] 12173/12173 games} -image {} -compound none -underline -1


The code is in tcl/utils/win.tcl
---------------------------------
proc ::docking::move_tab {srctab dsttab {x {}} {y {}}} {
  variable tbs
  if {$x != {}} {
    set dest [$dsttab index @[expr $x-[winfo rootx $dsttab]],[expr $y-[winfo rooty $dsttab]]]
  }
  # move tab
  set f [$srctab select]
  set o [$srctab tab $f]
  $srctab forget $f
puts "eval $dsttab add $f $o"
  eval $dsttab add $f $o

Merged into core-8-6-branch and trunk.

I have now documented the change of default value for the -compound widget option, see [81f4287d17]. Note that this is not in the ttk::label man page but in the ttk::widget man page.

Regarding the rest of my comments below dated 2019-12-31 11:53:22, there is nothing more to do: Since the default value for -compound in the LabelElementOptions is "none", InitializeElementRecord() will always use a value that is in the existing ttkCompoundStrings, even if the default value for the -compound widget option was changed to {}. The Ttk_Compound enum and the ttkCompoundStrings therefore are not in need of an update, and ditto for Ttk_GetCompoundFromObj(), LabelSetup(), LabelElementSize() and LabelElementDraw().

Based on my previous comment below, the fix should be to make an option of type TK_OPTION_STRING_TABLE support the TK_OPTION_NULL_OK flag. This is [601b77fbd3].

The test suite keeps being happy with this change.

The reported failing case now is working:

    package require Tk
    pack [::ttk::notebook .n] -fill both -expand true
    foreach tabs {Edit Check Close} {
        ::ttk::entry .n.[string tolower $tabs]
        .n add .n.[string tolower $tabs] -text $tabs
    }
    set srctab .n
      set f [$srctab select]
      set o [$srctab tab $f]
      $srctab forget $f
    puts "eval $srctab add $f $o"
      eval $srctab add $f $o

The test cases from [b82bd4872b] still work.

The ttk options management being a little bit complex, here is a commented test script with -compound taken as an example:

    package require Tk
    ttk::style theme use default
    set red_cross [image create photo -format gif -data {R0lGODlhBwAHAIABAP8AAP///
            yH5BAEKAAEALAAAAAAHAAcAAAIMBIKmsWrIXnLxuDMLADs=}]
    pack [ttk::label .l -image $red_cross -text Wish]

    # show default value of widget option: --> {}
    .l configure -compound

    # show default value of style option: --> the empty string
    ttk::style configure TLabel

    # at this stage, the label shows the image (red cross) only
    # this is correct because:
    #   - the widget option is {}  (i.e. NULL)
    #   - the dynamic setting from the widget state is also {}  (i.e. NULL)
    #   - the style option is not set  (i.e. NULL)
    #   - therefore Tk resorts to the default value specified at the time
    #     the "label" class was registered, i.e. to "none" (see the -compound
    #     option spec in LabelElementOptions[] in ttkLabel.c)

    # set the widget option to "left": this takes precedence over anything
    # --> the image is shown on the left of the text
    .l configure -compound left

    # set the style option to "bottom": this has no effect because the widget
    # option is set and has precedence
    ttk::style configure TLabel -compound bottom

    # reset the widget option: now the previously set style option is used
    # --> the image is shown at the bottom of the text
    .l configure -compound {}

    # reset the style option: the last resort (the element class option) is used
    # --> only the image is shown
    ttk::style configure TLabel -compound {}

Last but not least request to my TCT colleagues: we have been bitten in the ass with this already, so please review, test, and comment back here. Thanks!

The problem is created by the fix for [b82bd4872b], which allowed a new possible value {} for the -compound option. This was the identified way of allowing styling -compound as requested in this ticket.

However, in the process the following places have perhaps not been analyzed in enough depths:

- The Ttk_Compound enum and the ttkCompoundStrings. This is what is directly causing the error reported in the present ticket: Tk_SetOptions() returns TCL_ERROR in TtkWidgetConfigureCommand() or ConfigureTab() (depending on the widget $w) when executing $w configure -compound {}. Tk_SetOptions() checks that the string to which the user wants to set -compound matches one of the ttkCompoundStrings, which is not the case.

- Ttk_GetCompoundFromObj()

- LabelSetup(), LabelElementSize() and LabelElementDraw()

- The man page for ttk::label, describing the allowed values of -compound

- The default value for -compound in the LabelElementOptions, which is still "none". This one however is probably correct because this value is the 'elementDefault' last resort in InitializeElement() when the 'widgetValue', 'dynamicSetting', and 'styleDefault' are all NULL.

The first thing that comes to mind would be to add a "" value in the Ttk_Compound enum and a corresponding TTK_COMPOUND_EMPTY in the ttkCompoundStrings. However, this would not work because it would give the "" value to the option, instead of the intended NULL value. That's the precise reason TK_OPTION_NULL_OK exists.

Actually, I believe the real cause for the problem is that we have set the TK_OPTION_NULL_OK in an option of type TK_OPTION_STRING_TABLE while this combination is not supported. See the SetOptions man page. Quoting it: "Not all option types support the TK_OPTION_NULL_OK flag; for those that do, there is an explicit indication of that fact in the descriptions below.". And the description of TK_OPTION_STRING_TABLE does not mention support of TK_OPTION_NULL_OK.

Thanks for the report!

I believe this comes from [12f850f4550c8d4f] which is part of the fix for ticket [b82bd4872b].

Without actually trying it, the problem you are reporting looks like an unforeseen consequence of this fix.

I have to think about this a little bit.