[widget audit] toga.Table

[freakboy3742]

Audit of Table.

Includes an audit of Icon as well, because Icons can be used in tables.

Builds on #1955 because of dependencies on ListSource.

• Adds the ability to have a table with no header row.
• Renames on_double_click to on_activate to avoid a specific GUI action.
• Defaults to an empty string for missing data. This message was causing more confusion than benefit.
• Deprecates add_column in favor of a full insert/append capability.

Fixes:

• Fixes It is possible to reinitialize a table widget ? #623
• Fixes Text in table cell rendering on top of adjacent cell #700
• Fixes Table with leading number in heading #1467
• Fixes Table on windows does not fill container #1811
• Fixes On Windows clearing a Table puts it in an unstable state #2007
• Fixes Setting non-string data in to a ListSource on Android does not work #2070

Related:

• Use of GTK.TreeIter Raises DeprecationWarning #1993
• Examples do not support new ListSource APIs #2071

Audit checklist

• Core tests ported to pytest
• Core tests at 100% coverage
• Core docstrings complete, and in Sphinx format
• Documentation complete and consistently formatted
• cocoa backend at 100% coverage
• winforms backend at 100% coverage
• gtk backend at 100% coverage
• iOS backend at 100% coverage - no implementation
• android backend at 100% coverage - incomplete implementation not worth testing
• Widget support table updated
• Widget Issue backlog reviewed

[freakboy3742]

This is an interesting case of a subtle duck-typing change. The previous implementation would have allowed any object that honoured the (implicit) Source protocol; as a result of the tweak you made to core, the default behavior is "list like", and a Source must literally inherit from source, and any other type will be coerced (to varying degrees of success) into a ListSource. This then implies that ListSource will be robust to all possible input types, which I don't think is necessarily true.

[mhsmith]

After discussion, we agreed:

• The ListSource constructor already accepts any iterable.

• We need some way for the user to distinguish an iterable which is to be used as a Source directly, versus copied into a new ListSource. Inheriting the Source class is the simplest way of doing this.

• The statement "Any object that adheres to the collections.abc.MutableSequence protocol can be used as a data source" isn't really true, because:

  • The find method isn't part of the standard Sequence API.
  • There are also differences in whether the other methods use identity versus equality, as discussed in [widget Audit] toga.Selection #1955.

  So this wording should instead refer to the ListSource API directly, and that API documentation should include all the relevant dunder methods. Later we may redefine it as a Protocol.

[mhsmith]

@mhsmith #1811 and #2007 are both windows specific issues.

Confirmed that both of these are now fixed.

[mhsmith]

It turns out the Winforms ListView doesn't have a built-in select-all key combination, but I'll leave this here in case it's useful in the future.

[mhsmith]

Android issues:

• Setting non-string data in to a ListSource on Android does not work #2070
  • Fixed, and added to the list above.
• Android app crashes when Table contains too many cells #1392
  • It probably won't crash in the same way as it did with Rubicon, but the current implementation is obviously not scalable, so I've noted this in the documentation, and left Android marked as beta in the support table.