Code review comment for lp:~mhr3/dee-qt/changeset-support

When processing a transaction/changeset the row-* signals from Dee are used as synchronization points and since the Qt model signals are emitted during the transaction, there's really always just one row that needs to be skipped.

The primary thing here is that the skipping only happens when inside the row-* callback.

Consider how the transaction looks like in pseudocode:

// starting inside dee
var rows = dbus_signal.get_rows_iter();
while (rows.has_next())
{
  row = rows.next();
  var row_signal = this.submit_change(row, out iter);
  this.emit(row_signal, iter, () =>
  {
    // inside the signal emission we get into the DeeListModel plugin code
    if (consecutive_changes(iter)) processChange(...);
    else flushChangesAndProcessChange(() =>
    {
      beginRowsInserted(begin, end);
      // now qt will emit rowsInserted() or rowsRemoved()
      endRowsInserted(begin, end, () =>
      {
        // view code that will read the model
        for (int i = begin; i < end; i++)
          model.data(i, someRole); // at this point we need to skip the row that's currently being added (current iter, always just one)
      });
    });
  });
}

Of course the situation is different when the entire transaction is consecutive:
// starting inside dee
var rows = dbus_signal.get_rows_iter();
while (rows.has_next())
{
  row = rows.next();
  var row_signal = this.submit_change(row, out iter);
  this.emit(row_signal, iter, () => { processChange(...); }
}

this.emit(changeset_finished, () =>
{
  // inside the signal emission we get into the DeeListModel plugin code
  flushChanges(() =>
  {
    beginRowsInserted(begin, end);
    // now qt will emit rowsInserted() or rowsRemoved()
    endRowsInserted(begin, end, () =>
    {
      // view code that will read the model
      for (int i = begin; i < end; i++)
        model.data(i, someRole); // no need to skip anything, models are in sync
    });
  });
});