ANNOUNCE: Multi-column listbox and tree widget package Tablelist 5.9

[nemethi]

I am pleased to announce version 5.9 of the multi-column listbox and
tree widget package Tablelist.

What is new in Tablelist 5.9?
-----------------------------

1. Added the "-valign" column and cell configuration option, for
controlling the vertical alignment of embedded images and windows
(thanks to Trevor Williams for his proposal).

2. The "-stripebackground" and "-stripeforeground" options can now be
specified at column level, too (thanks to Christian Gollwitzer for
his proposal).

3. Improvements related to the Windows 7 platform.

4. Worked around a text widget bug in Tk versions 8.5 and later, related
to getting the index of the last line in the window if some of the
lines are elided (thanks to Bernhard Wallner for his bug report).

5. Corrected a typo in the implementation of the "rowconfigure"
subcommnad, introduced in the last Tablelist version (thanks to Jerzy
Witkowski for reporting this bug).

6. Fixed a bug related to resetting the "-(select)background" and
"-(select)foreground options at column, row, and cell levels,
introduced in the previous Tablelist version (thanks to Christian
Gollwitzer for his bug report).

7. Several further improvements in the code, demo scripts, and
documentation.

How to get it?
--------------

Tablelist is available for free download from the URL

http://www.nemethi.de

The distribution file is "tablelist5.9.tar.gz" for UNIX and
"tablelist5_9.zip" for Windows. These files contain the same
information, except for the additional carriage return character
preceding the linefeed at the end of each line in the text files for
Windows.

Tablelist is also included in tklib, which has the address

http://core.tcl.tk/tklib

How to install it?
------------------

Install the package as a subdirectory of one of the directories given
by the "auto_path" variable. For example, you can install it as a
directory at the same level as the Tcl and Tk script libraries. The
locations of these library directories are given by the "tcl_library"
and "tk_library" variables, respectively.

To install Tablelist on UNIX, "cd" to the desired directory and unpack
the distribution file "tablelist5.9.tar.gz":

gunzip -c tablelist5.9.tar.gz | tar -xf -

This command will create a directory named "tablelist5.9", with the
subdirectories "demos", "doc", and "scripts".

On Windows, use WinZip or some other program capable of unpacking the
distribution file "tablelist5_9.zip" into the directory "tablelist5.9",
with the subdirectories "demos", "doc", and "scripts".

The file "tablelistEdit.tcl" in the "scripts" directory is only needed
for applications making use of interactive cell editing. Similarly, the
file "tablelistMove.tcl" in the same directory is only required for
scripts invoking the "move" or "movecolumn" tablelist command. Finally,
the file "tablelistThemes.tcl" is only needed for applications using
the package Tablelist_tile (see next section).

Next, you should check the exact version number of your Tcl/Tk
distribution, given by the "tcl_patchLevel" and "tk_patchLevel"
variables. If you are using Tcl/Tk version 8.2.X, 8.3.0 - 8.3.2, or
8.4a1, then you should proceed as described in the "How to install it?"
section of the file "tablelist.html", located in the "doc" directory.

How to use it?
--------------

The Tablelist distribution provides two packages, called Tablelist and
Tablelist_tile. The main difference between the two is that
Tablelist_tile enables the tile-based, theme-specific appearance of
tablelist widgets; this package requires Tcl/Tk 8.4 or higher and tile
0.6 or higher. It is not possible to use both packages in one and the
same application, because both are implemented in the same "tablelist"
namespace and provide identical commands.

To be able to use the commands and variables implemented in the package
Tablelist, your scripts must contain one of the lines

package require tablelist ?version?
package require Tablelist ?version?

Likewise, to be able to use the commands and variables implemented in
the package Tablelist_tile, your scripts must contain one of the lines

package require tablelist_tile ?version?
package require Tablelist_tile ?version?

Since the packages Tablelist and Tablelist_tile are implemented in the
"tablelist" namespace, you must either import the procedures you need,
or use qualified names like "tablelist::tablelist".

For a detailed description of the commands and variables provided by
Tablelist and of the examples contained in the "demos" directory, see
the tutorial "tablelist.html" and the reference pages, all located in
the "doc" directory.

--
Csaba Nemethi http://www.nemethi.de mailto:csaba....@t-online.de

[Francois Vogel]

nemethi said on 26/05/2013 23:01:

> 4. Worked around a text widget bug in Tk versions 8.5 and later, related
> to getting the index of the last line in the window if some of the
> lines are elided (thanks to Bernhard Wallner for his bug report).

Could you please tell what tracker item you're referring to here?

Thanks,
Francois

[nemethi]

I don't know whether there is already a tracker item for the strange
text widget behavior that I experienced while examining an issue
reported by Bernhard, related to a tablelist widget having, among
others, a few hidden items. Some of the procedures contained in the
Tablelist code retrieve the index corresponding to @0,$y, where y is 1
less the body text widget's height. In some cases, the line component
of the resulting text index of the form line.char was by 1 greater than
the constant total number of text lines. This happened spuriously, and
only with Tk 8.5 and 8.6. Unfortunately, I haven't yet managed to
create a test script enabling one to reproduce this issue independently
of Tablelist.

[Francois Vogel]

nemethi said on 27/05/2013 23:19:

I think fixing this one:

http://sourceforge.net/tracker/?func=detail&atid=112997&aid=3574945&group_id=12997

would also fix what you have seen.

From my analysis the bug is that FinDLine does not properly consider
elided newlines (Tk 8.5+ only, 8.4 did not elide newlines). When
asking FinDLine for the DLine associated to an elided text index, the
display line returned is wrong (off by one).
I think (but did not check it) that when this happens at an index
located in an elided portion of text at the end of the text widget,
it's possible to obtain a li.ch index with "li" greater (by 1) than
the last line number of the text widget.

I should dive into this issue once more but I'm lacking time these
days (well, ok, these months). I'm happy with anybody faster than me
in fixing this.

F.

[nemethi]

Many thanks for your deep analysis. It seems to fully confirm the text
index errors encountered during my tests.

[fsvog...@free.fr]

Some news on the below pretty old story related to elided newlines in the text widget:

I have made some work regarding this issue and I believe the original problem reported in the ticket does no longer happen:

http://core.tcl.tk/tk/tktview/3574945fffffffffffffffffffffffffffffffff

Work continues however, there are still things to do to make elided newlines fully supported by the text widget.

See fossil branch text-elided for the details. Comments and test cases welcome.

Regards,
F.

Le mardi 28 mai 2013 23:04:06 UTC+2, nemethi a écrit :
> Am 28.05.2013 21:54, schrieb Francois Vogel:
> > nemethi said on 27/05/2013 23:19:
> >> Am 27.05.2013 21:29, schrieb Francois Vogel:
> >>> nemethi said on 26/05/2013 23:01:
> >>>> 4. Worked around a text widget bug in Tk versions 8.5 and later,
> >>>> related
> >>>> to getting the index of the last line in the window if some of the
> >>>> lines are elided
> >>>

> >>> Could you please tell what tracker item you're referring to here?
> >>

[nemethi]

This is good news, thanks for looking into this issue.

[Francois Vogel]

nemethi a écrit le 15/12/2014 22:35 :
>
> This is good news, thanks for looking into this issue.
>

I'm not 100% sure that the issue you are experiencing with Tablelist
is the same as

http://core.tcl.tk/tk/tktview/3574945fffffffffffffffffffffffffffffffff

Could you perhaps try if your problem still happens or not (in branch
text-elided)?

Thanks,
F.

[nemethi]

I have built a new Tk version with your changes from the "text-elided"
branch. With the new version, the problems I had in Tablelist (caused
by bad text widget index of the last line in the window if some of the
lines are elided) seem to have become less frequent, but, unfortunately,
they are still present.

The good news is that I have at last managed to write a simple sample
script (independent of Tablelist) that hopefully will help you find the
relevant bug in the text widget code. Here is the script:

text .t
.t tag configure hiddenLine -elide 1
.t insert end aaa\n
.t insert end bbb\n
.t insert end ccc
pack .t -expand yes -fill both

after 2000 {
# Hide the last 2 lines
puts "\nHiding the last 2 lines"
.t tag add hiddenLine 2.0 3.end+1c
}

after 4000 {
# Show the last 2 lines again - version #1
puts "\nShowing the last 2 lines again - version #1"
.t tag remove hiddenLine 2.0 3.end

printBottomIdx
}

after 6000 {
# Show the last 2 lines again - version #2
puts "\nShowing the last 2 lines again - version #2"
.t tag remove hiddenLine 2.0 3.end+1c

printBottomIdx
puts "\nFinished"
}

# Prints the index @0,300
proc printBottomIdx {} {
set idx [.t index @0,300]
puts -nonewline $idx

set line [expr {int($idx)}]
if {$line > 3} {
puts " - BAD line number $line !!!"
} else {
puts " - OK"
}
}

Just start the script in a Linux console and wait for a few seconds,
until the "Finished" message is displayed. The only difference between
the "BAD line number ..." and "OK" cases is in the 2nd index passed to
"tag remove ...". Actually, version #2 is more correct, but,
nevertheless, version #1 must not give rise to a bad text index, either.


P.S.: On Dec. 16 I wrote a reply to your private mail, but it wasn't
delivered to you, due to a blacklist condition (the SMTP server of my
provider seems to send too much SPAM to free.fr). Anyway, in that mail
I just wanted to let you know that I couldn't do anything before the
start of this week.

Best regards,

Csaba

[Francois Vogel]

nemethi a écrit le 22/12/2014 20:29 :
> The good news is that I have at last managed to write a simple
> sample script (independent of Tablelist) that hopefully will help
> you find the relevant bug in the text widget code.

I'm wondering whether there is a bug here or not. Without any elided
line, take a look at this trimmed down version of your test case:

package require Tk
pack [text .t]
.t insert end "aaa\nbbb\nccc"
pack .t
.t index 3.end ; # returns 3.3
.t index 3.end+1c ; # returns 4.0
.t index end ; # returns 4.0


From the man page for the text widget:

INDICES
[...]
line.char
Indicates char'th character on line line. [...] If char is end
then it refers to the newline character that ends the line.

--> therefore: .t index 3.end correctly returns 3.3 because this
is the index of the newline that ends line 3.


Also, still from the man page for the text widget:

INDICES
[...]
end
Indicates the end of the text (the character just after the last
newline).

--> therefore: .t index end correctly returns 4.0 because the
last newline being at position 3.3 (it's a dummy newline marking the
end of the widget), the index 4.0 refers to the character just after
this last newline.

Also .t index 3.end+1c correctly returns 4.0 because, in this
example, '3.end+1c' refers to the same index as 'end' since there is
no character after the character located just after the last (dummy)
newline.


IMO there is no bug here:

- The index at '3.end' refers to the newline at end of line 3, which
is also the last newline of the text widget.
- The index 'end' refers to the character just *after* the last newline

Consequence: '3.end' and 'end' do not refer to the same index.


Then, what can be seen with elided lines:

.t tag configure hiddenLine -elide 1

.t tag add hiddenLine 2.0 3.end+1c

.t tag remove hiddenLine 2.0 3.end

.t index @0,300

--> returns 4.0

.t tag remove hiddenLine 2.0 3.end+1c

.t index @0,300

--> returns 3.3

Which one is correct is a good question. Perhaps .t tag add
hiddenLine 2.0 3.end+1c should just not elide the last newline of
the text widget.

Cheers,
Francois

[nemethi]

That is my opinion, too.

>
> - The index at '3.end' refers to the newline at end of line 3, which is
> also the last newline of the text widget.
> - The index 'end' refers to the character just *after* the last newline
>
> Consequence: '3.end' and 'end' do not refer to the same index.
>

Correct.

>
> Then, what can be seen with elided lines:
>
> .t tag configure hiddenLine -elide 1
> .t tag add hiddenLine 2.0 3.end+1c
> .t tag remove hiddenLine 2.0 3.end
> .t index @0,300
>
> --> returns 4.0
>
> .t tag remove hiddenLine 2.0 3.end+1c
> .t index @0,300
>
> --> returns 3.3
>
> Which one is correct is a good question. Perhaps .t tag add hiddenLine
> 2.0 3.end+1c should just not elide the last newline of the text widget.
>

IMHO, ".t index @0,300" mustn't return 4.0, because the latter
corresponds to the index end. Also, IMHO, it is OK that ".t tag add
hiddenLine 2.0 3.end+1c" elides the last newline. Strictly speaking, in
this example there is no *explicitly inserted* newline preceding the
index end, but this fact shouldn't change the overall behavior.

> Cheers,
> Francois
>

Many thanks for your work! I have seen a lot of changes you made on the
"text-elided" branch, and I am sure this was a quite considerable
effort, due to the fact that the text widget implementation is awfully
complex.

[Francois Vogel]

nemethi a écrit le 23/12/2014 11:25 :
> IMHO, ".t index @0,300" mustn't return 4.0, because the latter
> corresponds to the index end. Also, IMHO, it is OK that ".t tag add
> hiddenLine 2.0 3.end+1c" elides the last newline. Strictly
> speaking, in this example there is no *explicitly inserted* newline
> preceding the index end, but this fact shouldn't change the overall
> behavior.

Agreed. I have just opened a ticket to follow up with this issue:

http://core.tcl.tk/tk/tktview/c199ef90a67fa4ea440eac10aabbb28c532a74c7

> Many thanks for your work! I have seen a lot of changes you made on
> the "text-elided" branch, and I am sure this was a quite
> considerable effort, due to the fact that the text widget
> implementation is awfully complex.

Thanks. Indeed it is... say, less than straightforward! But the test
suite helps a lot to avoid regressions.

I still know about one issue to fix in the text-elided branch, and
also have to take a closer look at some code snippets directly making
use of byteIndex==0 (suspicious, with elided newlines). Nevertheless,
at some point not too far away from now I would be happy in receiving
feedback from people willing to test for non regressions in their use
of the text widget, be it with or without elided lines. If you can go
on using the text widget from text-elided branch and report what you
find that would help a lot.

Regards,
F.

I would be happy

[Francois Vogel]

Francois Vogel a écrit le 23/12/2014 11:36 :
> I have just opened a ticket to follow up with this issue:
>
> http://core.tcl.tk/tk/tktview/c199ef90a67fa4ea440eac10aabbb28c532a74c7

Bug fixed proposed there, thanks for your testing if you can.

Regards,
F.

[nemethi]

I have just successfully tested this bugfix, many thanks for your quick
reaction!

[nemethi]

Am 23.12.2014 um 12:14 schrieb Francois Vogel:

Hi Francois,

First, I wish you a Happy New Year!

I have just stumbled across a text widget problem related to embedded
windows. To reproduce it, please run the following simple script with
your Tk version built from the "text-elided" branch:


pack [text .t]

proc createLabel text {
if {![winfo exists .t.l]} {
puts "creating label with text '$text'"
label .t.l -text $text
}

return .t.l
}

.t window create 1.0 -create {createLabel "Label 1"}

after 2000 {
destroy .t.l
.t window configure 1.0 -create {createLabel "Label 2"}
}


On my Linux box, the script first displays

creating label with text 'Label 1'

Two seconds later it displays

creating label with text 'Label 1'
creating label with text 'Label 2'

... and a message box with the following error message:

window name "l" already exists in parent
window name "l" already exists in parent
while executing
"label .t.l -text $text"
(procedure "createLabel" line 4)
invoked from within
"createLabel "Label 1""

This is quite strange, because the createLabel procedure checks whether
the label .t.l exists. Although "winfo exists .t.l" returns 0, the
error message states that the window .t.l already exists.

The expected behavior is that text "creating label with text 'Label 1'"
should only be displayed once, immediately after starting the interpreter.

The above script works as expected with the official Tk releases (tested
with Tk 8.4, 8.5, and 8.6).

Could you please find some time to look into this issue? Many thanks in
advance!

[Francois Vogel]

nemethi a écrit le 01/01/2015 22:03 :
>
> I have just stumbled across a text widget problem related to
> embedded windows. To reproduce it, please run the following simple
> script with your Tk version built from the "text-elided" branch

Very strange... I can't reproduce directly (but see below...!),
neither on Windows nor on Linux.

For me, on both boxes the behavior is what is expected, i.e. when I
paste your script in a tclsh window (here for instance in a build from
the text-elided branch) the output is as follows:

% package require Tk
8.5.17
% pack [text .t]
%
% proc createLabel text {

if {![winfo exists .t.l]} {
puts "creating label with text '$text'"
label .t.l -text $text
}

return .t.l
}

%
% .t window create 1.0 -create {createLabel "Label 1"}
%

creating label with text 'Label 1'

% after 2000 {

destroy .t.l
.t window configure 1.0 -create {createLabel "Label 2"}
}

after#0
% creating label with text 'Label 2'


No double message "creating label with text 'Label 1'", and no error
message.


Besides this difference in behavior between what we see, I think I can
shed some light on this. OK, that's a bit tricky.

My understanding is that what you're seeing probably comes from the
following commit of mine (note: I further reworked this version of
FindDLine later):

[dc9f4bea9f] Fixed FindDLine again (the previous fix [575b376065] was
an improvement despite it did not fix all cases), see case 'C' in bug
[7703f947aa]

This commit was followed by two further commits fixing some tests
regarding embedded windows:
- [13d2fcd25d] Fixed embedded windows tests that were failing
following [dc9f4bea9f] - See comment in bug [7703f947aa]
- [8dfc0f1731] Fixed embedded windows tests that were failing (on
Linux) following [dc9f4bea9f] - See comment in bug [7703f947aa]

In short, FindDLine is a function of the text widget code that finds
the display line containing a given index. I found that this function
was just wrong in some cases (well, IMO...!), even without elided
text, and could return the wrong display line. FindDLine just did not
what is stated in its header documentation, and what is expected by
its callers.

I rewrote this function FindDLine, and this rewrite triggered new
failures in the test suite.

As explained in my comment dated 2014-12-03 07:07:12 in bug
[7703f947aa], I believe these tests were not correct:
"
This commit fixed FindDLine so that it really provides the correct
display line to its caller, in all cases including fully elided lines.
The fix makes use of TkTextFindDisplayLineEnd to check, in FindDLine,
if the desired index is on the last display line of the text widget or
not. The previous version of FindDLine did not call
TkTextFindDisplayLineEnd.
It turns out that calling TkTextFindDisplayLineEnd launches the couple
LayoutDLine/FreeDLine, which has the undesired effect of mapping and
unmapping the embedded windows laying on the last (in this call
conditions) display line of the widget.
In turn, this triggers the differences in the results of the tests
mentioned above: the complementary errors returned are due to this
added mapping/unmapping of embedded windows triggered when looking if
the index is on the last display line of the widget.
This call to LayoutDLine/FreeDLine is indeed documented in
textDisp.c:3365-3370. I believe this was not considered as a bug so
far, rather as a room for improvement regarding performance. Therefore
I have fixed the failing tests (sprinkled a few updates here and
there) and kept TkTextFindDisplayLineEnd unchanged.
This is what [13d2fcd25d] does.
"

So an added update in your code could help (just my guess). But this
may not be an option for you, update being potentially harmful.

Besides, I can furthermore see the following strange thing:

1. Paste this in tclsh:

package require Tk

pack [text .t]
proc createLabel text {
if {![winfo exists .t.l]} {
puts "creating label with text '$text'"
label .t.l -text $text
}
return .t.l
}
.t window create 1.0 -create {createLabel "Label 1"}

So far, so good.

2. Type manually:

destroy .t.l

and then two unexpected things happen:
a. I get the message: "creating label with text 'Label 1'" in the
tclsh shell window.
b. the embedded window is still visible in the text widget.

This is in both trunk (8.6) and text-elided.

I would say there is something else behind this than my changes in
text-elided. The embedded window does not get destroyed. More fixes
are probably needed. This seems to deserve a ticket in the Tk tracker.

Thanks for the feedback, i appreciate it very much.

Regards,
F.

[Francois Vogel]

Francois Vogel a écrit le 02/01/2015 01:18 :
> My understanding is that what you're seeing probably comes from the
> following commit of mine (note: I further reworked this version of
> FindDLine later)

Note that in the latest version of FindDLine no call to
TkTextFindDisplayLineEnd happen anymore (precisely to avoid
mapping/unmapping of the embedded windows). The problem you see seems
however to be still present (what exact date/time is your pull of
text-elided branch? I have removed the call to
TkTextFindDisplayLineEnd from FindDLine on 2014-12-30 at 14:59).

I really think we should dive into what happens (in trunk, or
core-8-5-branch, to be free from my changes in text-elided branch) when:

> 1. Paste this in tclsh:
>
> package require Tk
> pack [text .t]
> proc createLabel text {
> if {![winfo exists .t.l]} {
> puts "creating label with text '$text'"
> label .t.l -text $text
> }
> return .t.l
> }
> .t window create 1.0 -create {createLabel "Label 1"}
>
> So far, so good.
>
> 2. Type manually:
>
> destroy .t.l
>
> and then two unexpected things happen:
> a. I get the message: "creating label with text 'Label 1'" in the
> tclsh shell window.
> b. the embedded window is still visible in the text widget.

Regards,
F.

[nemethi]

Hi Francois,

I last pulled the sources from the text-elided branch on Dec. 23. I
will perform an update to make sure I have the latest version, and will
repeat the test with the newly built Tk version. I hope I can do this
within the next one or two hours.

[nemethi]

Hi Francois,

I have repeated the test with the most recent version of tkTextDisp.c,
with the result that the script now works as expected.

What you wrote about the "two unexpected things" above might be the
expected behavior. From the "text" man page, section "EMBEDDED
WINDOWS", option "-create script":

"... If the annotation's window should ever be deleted, script will be
evaluated again the next time the annotation is displayed."

Many thanks again for all your effort put into improving the really
complex text widget implementation!

[Francois Vogel]

nemethi a écrit le 02/01/2015 13:03 :
> I have repeated the test with the most recent version of
> tkTextDisp.c, with the result that the script now works as expected.

Great. That's thanks to [8d7a4443f7].

> What you wrote about the "two unexpected things" above might be the
> expected behavior. From the "text" man page, section "EMBEDDED
> WINDOWS", option "-create script":
>
> "... If the annotation's window should ever be deleted, script will
> be evaluated again the next time the annotation is displayed."

Yes I had read that line too before writing.

I thought that it means that when the embedded window gets
undisplayed, e.g. because it is off screen, or obscured by another
item, or out of the visible part of the text, then the -create window
will be run again when the embedded window needs to be displayed again
(i.e. when it's again visible on screen).

Another interpretation is that this sentence seems to say that any
attempt to delete the embedded window will run the -create script
again if the embedded window index position is still on screen? Isn't
this unexpected? Why such a behavior?
That means that "destroy.t.l" cannot be used to remove an embedded
window from a text widget since it:
1. runs the -create script again
2. has no effect with respect to removing the window from the text
widget.

Well, why not after all...

> Many thanks again for all your effort put into improving the really
> complex text widget implementation!

A lot of fun, as you know...!

Thanks for your continuing testing.

Regards,
F.

[nemethi]

Am 02.01.2015 um 15:50 schrieb Francois Vogel:
> nemethi a écrit le 02/01/2015 13:03 :
>> What you wrote about the "two unexpected things" above might be the
>> expected behavior. From the "text" man page, section "EMBEDDED
>> WINDOWS", option "-create script":
>>
>> "... If the annotation's window should ever be deleted, script will be
>> evaluated again the next time the annotation is displayed."
>
> Yes I had read that line too before writing.
>
> I thought that it means that when the embedded window gets undisplayed,
> e.g. because it is off screen, or obscured by another item, or out of
> the visible part of the text, then the -create window will be run again
> when the embedded window needs to be displayed again (i.e. when it's
> again visible on screen).
>
> Another interpretation is that this sentence seems to say that any
> attempt to delete the embedded window will run the -create script again
> if the embedded window index position is still on screen? Isn't this
> unexpected? Why such a behavior?
> That means that "destroy.t.l" cannot be used to remove an embedded
> window from a text widget since it:
> 1. runs the -create script again
> 2. has no effect with respect to removing the window from the text
> widget.
>
> Well, why not after all...
>

This is yet another text widget story. Consider the following simple
script:


pack [text .t -height 5] -expand yes -fill both

proc createLabel line {
set w .t.l$line
if {![winfo exists $w]} {
puts "creating label $w"
label $w -text "Label $line"
}

return $w
}

for {set line 1} {$line <= 10} {incr line} {
.t window create $line.0 -create [list createLabel $line]
.t insert end \n
}

after 2000 {
puts "\n2 seconds later:"
for {set line 1} {$line <= 10} {incr line} {
destroy .t.l$line
}
}


On my Linux box, with Tk 8.5 and 8.6, I get the output:

creating label .t.l1
creating label .t.l2
creating label .t.l3
creating label .t.l4
creating label .t.l5
creating label .t.l6
creating label .t.l7
creating label .t.l8
creating label .t.l9
creating label .t.l10

2 seconds later:
creating label .t.l1
creating label .t.l2
creating label .t.l3
creating label .t.l4
creating label .t.l5
creating label .t.l6
creating label .t.l7
creating label .t.l8
creating label .t.l9
creating label .t.l10

Actually, the text widget (of height 5) can only display 4 lines
(because the embedded labels make the lines a bit higher). For this
reason, IMHO it is a bug that all 10 labels get created (and recreated).

With Tk 8.4, only 4 labels are created. IMO, this is the correct behavior:

creating label .t.l1
creating label .t.l2
creating label .t.l3
creating label .t.l4

2 seconds later:
creating label .t.l1
creating label .t.l2
creating label .t.l3
creating label .t.l4

I had reported this bug in October 2006 (item #1581955), as follows:


In Tk 8.5, the text widget command

<path> window create <index> -create <script>

doesn't behave as expected. From the man page:

"... this script will be evaluated when the annotation
is about to be displayed on the screen. ... If the

annotation's window should ever be deleted, script will
be evaluated again the next time the annotation is
displayed."

In earlier Tk versions, the window's creation was
delayed indeed as specified in the man page, i.e.,
until effectively displaying it on the screen. This
was a very useful feature, allowing the creation of a
large number of embedded windows, of which only a few
had to really exist. For example, whenever vertical
scrolling or anything else made it necessary to update
the view, it was possible to destroy the windows
embedded into the other lines. A very effective way to
save resources and avoid problems related to keyboard
navigation with the Tab key (which becomes awfully slow
in the presence of a large number of windows).

In Tk 8.5, the "-create" option behaves basically like
"-window". The [window names] subcommand returns the
names of *all* embedded windows, and it is quite easy
to see that all of these really exist. Any attempt to
delete some of them fails, because they are immediately
recreated, contrary to what is stated in the documentation.

---

Comment By: Csaba Nemethi (nemethi)
Date: 2009-10-20 14:25

Message:
Any chance to see this annoying bug fixed in the near future?

---

Comment By: Donal K. Fellows (dkf)
Date: 2010-01-05 01:11

Message:
Bluntly, there's not much chance of fixing this unless we can find
someone who really groks the (now horrendously complex) text widget code
in enough detail. My suspicion/hunch is that it'll be hard to fix
because we now need the dimensions of the embedded windows much earlier
so that we can get smooth scrolling right.

---

Comment By: Francois VOGEL (fvogelnew1)
Date: 2012-05-17 13:22

Message:
Test script:

pack [text .t]
for {set i 1} {$i < 100} {incr i} {
.t insert end $i\t$i--$i--$i--$i--$i\n
}
proc cremwin {} {
puts "NOW running the -create script"
return [entry .t.e2]
}
# create embedded window out of the currently visible area
# In Tk 8.5 the message displays as soon as we hit enter
# on next line - BUG
# In Tk 8.4 the message displays only when scrolling down
# so that line 50 becomes visible - OK
.t window create 50.5 -create cremwin


From the above I conclude that this problem is probably very hard to
solve. For Tablelist I found the following workaround: Immediately
after invoking "window create", I apply an elided tag to the respective
text position. This prevents the embedded window from being effectively
created. Then, whenever the visible portion of the tablelist's body
text widget changes, I remove that tag from the embedded windows of the
currently visible lines (this will trigger the respective creation
scripts), apply it to the other embedded windows, and destroy the
latters (again, due to that elided tag, the windows just deleted won't
get recreated). Not really the fine English art, but it does the trick.

Now, what should be the next step regarding this bug report (submitted
over 8 years ago)? If it would really need too much work to restore the
behavior known from Tk 8.4 and earlier, I think the man page should be
corrected accordingly and extended by the following 3 comments:

1) Eliding an embedded window immediately after scheduling it for
creation via "window create" will prevent it from being effectively created.

2) Uneliding an elided embedded window will automatically trigger the
associated creation script.

3) After destroying an elided embedded window, the latter won't get
automatically recreated.

Just a possible way towards closing that bug item.

[Francois Vogel]

nemethi a écrit le 02/01/2015 19:12 :
> This is yet another text widget story. Consider the following
> simple script:

[...]

> I had reported this bug in October 2006 (item #1581955)

Yes, this bug is now tracked here:

http://core.tcl.tk/tk/tktview?name=1581955fff

Also, I believe this one is the same:

http://core.tcl.tk/tk/tktview/1591493fff

> From the above I conclude that this problem is probably very hard to
> solve. For Tablelist I found the following workaround: Immediately
> after invoking "window create", I apply an elided tag to the
> respective text position. This prevents the embedded window from
> being effectively created. Then, whenever the visible portion of
> the tablelist's body text widget changes, I remove that tag from the
> embedded windows of the currently visible lines (this will trigger
> the respective creation scripts), apply it to the other embedded
> windows, and destroy the latters (again, due to that elided tag, the
> windows just deleted won't get recreated). Not really the fine
> English art, but it does the trick.
>
> Now, what should be the next step regarding this bug report
> (submitted over 8 years ago)? If it would really need too much work
> to restore the behavior known from Tk 8.4 and earlier, I think the
> man page should be corrected accordingly and extended by the
> following 3 comments:
>
> 1) Eliding an embedded window immediately after scheduling it for
> creation via "window create" will prevent it from being effectively
> created.
>
> 2) Uneliding an elided embedded window will automatically trigger
> the associated creation script.
>
> 3) After destroying an elided embedded window, the latter won't get
> automatically recreated.

That's interesting.

I'm willing to try to look at this bug, but this can only happen for
me after the text-elided work is finished, i.e. after having merged
the text-elided to core--8-5-branch.

In the meantime, I think it's better to continue adding comments and
leads to:

http://core.tcl.tk/tk/tktview?name=1581955fff

(could you please post there what you did to work around this issue?).
That would avoid spreading the information, even if it could reduce a
bit the visibility of the issue which I understand is the reason why
you posted here ;-)

Best regards,
F.