* Require the deleted row to have been removed from the
model before calling uiTableModelRowDeleted.
* Require the row count to be updated before calling
uiTableModelRowDeleted.
Notes
-----
darwin: Does not care about row counts internally.
unix: Requires the row to have been deleted prior to
calling this function:
> This should be called by models after a row has been removed.
> The location pointed to by path should be the location that the
> row previously was at. It may not be a valid location anymore.
windows: Does not state anything in the documentation but does keep
track of its own row count internally.
* Require the new row to have been added to the model
before calling uiTableModelRowInserted.
* Require the row count to be updated before calling
uiTableModelRowInserted.
Notes
-----
darwin: does not care about row counts internally. From the docs:
> The numberOfRows in the table view is automatically increased
> by the count of indexes.
unix: does not state anything regarding order in the documentation.
windows: does not state anything in the documentation but does keep
track of its own row count internally.
So in theory we do not have to require increasing the row count before
calling uiTableModelRowInserted, but just by the very nature of the
function name (past tense) we should.
Let's stop sending mixed signals about the build status in the CI environment; Travis and AppVeyor both used "the latest build" by default, and not "master", and apparently this confused people. See https://news.ycombinator.com/item?id=16331432 for an example.
MinGW-w64 recently added manual workarounds directly into the class via overloads that make existing Direct2D code source-compatible. However, that exposed an error in my definition of the typedefs I was using in my own workaround: both of these methods are const, even in MSVC, but I neglected to include the const qualifier. I'm not sure how this code compiled in the past, but now the overload resolution engine finds no match.
I want to remain compatible with versions of MinGW-w64 old enough to not have their fix, so our fix remains.
Fixes#446.