Recent changes to bugs

#271 TableDisplay() is broken by default in X11

Christopher Chavez — Fri, 27 Nov 2020 14:34:11 -0000

I'm not sure the Xft clipping bug in core Tk was ever reported; it still exists, so I have opened a ticket: https://core.tcl-lang.org/tk/info/4476fd6144

#309 Visual artifacts in Tktable cells with MacOSX Cocoa tk

Christopher Chavez — Fri, 11 Sep 2020 21:02:13 -0000

I am now prompted to believe there were two separate issues: the one originally reported here, which may have been resolved by Tk at some point; and a new one which I believe was introduced in Tk Aqua 8.6.9. I likely unintentionally hijacked this ticket, as both issues have slightly similar descriptions, same steps for reproducing, and same -drawmode slow workaround.

The new issue will be resolved by Tk Aqua 8.6.11, which now has a working XSetClipRectangles() implementation (https://core.tcl-lang.org/tk/info/b505e5f6a9). But in order to take advantage of it, Tktable must be recompiled with a tiny change (undefine NO_XSETCLIP in tkTable.c; I am attaching a more complete patch provided to me by Marc Culler, a Tk Aqua developer). Once this is done, -drawmode slow should no longer be used in order to avoid the fuzzy text observed on Retina displays.

#309 Visual artifacts in Tktable cells with MacOSX Cocoa tk

Christopher Chavez — Mon, 13 Apr 2020 15:30:48 -0000

Someone who reported this same issue on comp.lang.tcl notices that the -drawmode slow workaround causes fuzzy text when using a Retina display.

Normal cells (not overflowing with text):

Fuzzy cells when using -drawmode slow:

I believe this is because -drawmode slow causes the entire table to be drawn into a pixmap, but text and other content drawn into pixamps is being done at non-Retina (1x) scale, and so when the pixmap is drawn to the screen, it is magnified 200% and antialiased, resulting in fuzzy text. I have opened another Tk ticket for this: https://core.tcl-lang.org/tk/info/e2e9ce70b2

Resolving this might mean that either Tk should make drawing into pixmaps "Retina-aware" (which I suspect there are issues with doing so), or Tktable should not draw into pixmaps (maybe there are issues with doing this as well).

#309 Visual artifacts in Tktable cells with MacOSX Cocoa tk

Christopher Chavez — Wed, 08 Apr 2020 08:50:02 -0000

I have investigated this issue further and filed a Tk bug: https://core.tcl-lang.org/tk/info/685ac3072790118c

The problem is that, on Aqua, any cells with overflowing text will have their text erroneously appear behind the text of every later cell (i.e. a cell in a later column in the same row, or a cell in a later row) with overflowing text (unless -drawmode slow is used). The problem is more clearly seen by overflowing a cell with whitespace or non-overlapping text:

Examining the drawing code in TableDisplay() (tkTable.c), the clipWind pixmap is used when cells have overflowing text: the background and contents already drawn to the cell are copied into clipWind using XCopyArea() the text is then drawn into clipWind and then only the text-containing portion of the cell is copied from clipWind into window using XCopyArea(). The assumption is that existing contents of clipWind are overwritten by the first XCopyArea() for each cell that uses it, but this fails on Aqua, except for -drawmode slow, where window is a pixmap rather than the actual window (the pixmap gets copied to the actual window with XCopyArea() after the entire table is drawn into it).

So this would indicate XCopyArea() is broken on Aqua, at least when the source is not a pixmap, which seems to likely be the case. When the source of an XCopyArea() operation is an actual window rather than a pixmap, it relies on a known-broken function TkMacOSXBitmapRepFromDrawableRect(), which as I understand it, is broken due to the limitation of there being no apparent way to read from a Mac window's "backing store" and get a bitmap or other representation of what has already been drawn so far; maybe the issue is unfixable without drastic changes to Tk.

Some workarounds seem possible from Tktable. It could always use an approach similar to -drawmode slow on Aqua (I'm not sure it's even perceptibly "slow" compared to the other drawing modes on Aqua). Another would be to recreate clipWind for each cell that uses it (this might be the easiest change, since it only involves moving 2 statements). Another is to avoid using XCopyArea() with window as the source, by redrawing into clipWind what is currently being copied into it, draw the text into clipWind, and then only use XCopyArea() to copy the result from clipWind into window (I have not had success with this approach; maybe there is a problem in XCopyArea() even when the source is a pixmap). But I have not completely verified if any of these workarounds truly work, e.g. when using embedded windows.

#309 Visual artifacts in Tktable cells with MacOSX Cocoa tk

Christopher Chavez — Sun, 12 May 2019 11:33:34 -0000

This issue seems to still be present under Tk 8.6.9.1 (encountered by a user of Tcl::pTk::TableMatrix: https://rt.cpan.org/Ticket/Display.html?id=129543)

Any updates on this? Is this an upstream Tk issue (was a ticket ever opened)?

#318 project status and documentation

Jeffrey Hobbs — Tue, 20 Feb 2018 06:17:27 -0000

Yes - multiple columns
Yes - images in any cell, though done different from treeview
I think it has Py3 support (as part of tkinter?)
Screenshots are on the wiki.

project status and documentation

buhtz — Fri, 16 Feb 2018 13:01:23 -0000

What is the current status of the project?

Can I have multiple columns?
Can I use images in the columns - not only in the first one (like
tkinter.Treeview is restricted)
Python3 support?
screenshots
example code

#300 TkTable version in man page is wrong (2.8), should be 2.10

Mark Ramsell — Sun, 11 Jun 2017 15:34:31 -0000

Problem: bad man page

New file for "tkTable.3tk.gz" This file has been modified from package tk-table_2.10-3_amd64.deb. In Ubuntu (various flavors) 16.04 the ".OP" was changed to ".OPP" possibly for some 'groff' conflict. Also fixed the ".CS" line that was too long at the end of the file.

Also attached a diff file for patching, if that is desired.

#317 Can I upload the wrapper library for tktable on PyPI?

Nelson — Thu, 01 Sep 2016 13:53:29 -0000

Note: to make it available on PyPI, it would probably be nice that as part of the eventualpip install tktable also the original tktable is installed automatically, in case it isn't already in the user's system.

Can I upload the wrapper library for tktable on PyPI?

Nelson — Thu, 01 Sep 2016 13:51:47 -0000

Hi,

I've a uploaded the Python wrapper library for tktable on Github, so that people could obtain it more easily, since nowadays Github is highly used. I was wondering if there would be any problems in uploading this wrapper library to PyPI, in terms of license.

Thanks for your support!