[GSoC status report] Week 6

[Teo Mrnjavac]

The first official week of GSoC coding was week 6 for me, and as
predicted last week, SortMap::deleteRows() and SortMap::insertRows()
have proven to be a PITA to implement well.
First the good news: I have discovered a logical flaw in my plans to
use Qt's qStableSort() which has been eluding me for a while - this
has been worked around and SortMap::sort() now doesn't return wacky
results after the first pass any more, but the current solution is
less than ideally efficient. I'd say that the only reasonable thing
for me to do would be to reimplement a sorting algorithm manually.
I also optimized the ctor a little bit, and fixed an issue when the
view was not updated when a sorting scheme is applied.
Now the bad: during this week I began implementing
SortMap::deleteRows() and I attempted some ways to keep m_map
consistency, these attempts failed. Then I tried an alternative
approach: rather than try to restore the consistency of a modified
m_map, why not just resort it? So I implemented kAdaptiveStableSort(),
a simple generic adaptive sorting algorithm that should perform close
to O(n) on a partially sorted input. This was very promising,
unfortunately I realized only later that even though this algorithm
will very likely be useful later on, in this case I can't use it
because I have no guarantee that the user is deleting from a cleanly
sorted m_map.

So it all boils down to the issue we discussed last week: is sorting a
state or an action, and how should the whole thing behave when the
user modifies a sorted playlist?
During week 7 I need to figure out what to do with the SortMap
consistency, and to do that we need to decide if sorting is an action
or a state, and if modifying a sorted playlist should result in the
order being applied to the model, or reset, or updated, or something
else entirely. Also I have noticed that the view is quite tightly
coupled with the FilterProxy, so that needs to be addressed too.