| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
down problems with move().
|
|
They worked because "T" was always being used as an integer-compatible type.
|
|
|
|
I'm beginning to suspect that I'll want to replace dynamic lists
with something that exposes a more tab-specific behavior after all.
Most importantly, I think the model maybe should not *have* information
about the order of the tabs -- including that complicates the interface
and adds more information to keep in sync (with the associated usual
problems, e.g., when the user moves a tab, does the view call back into
the model, and how does it avoid an infinite loop?).
|
|
into a bad index.
I swapped the arguments to insert(); whoops!
|
|
|
|
|
|
collection.
|
|
tests.
I'm not sure the multi-index container is the most parsimonious
implementation -- it might be better to use a simple vector or deque,
since we have to pay for a linear traversal anyway -- but at this point
I want to just *stop* and move on to the next step. This implementation
is good enough, and more importantly, I think the interface is finally
right.
|
|
It's buggy, so they fail right now.
|
|
to match.
Specifically, I changed append() to a general insert() routine and
added a move() routine, updating signals to correspond.
I decided that although this imposes a bit more on clients of the
interface (they need to support more signals and more general signals),
it's probably better in the long run. It makes the list interface less
surprising; it also makes it possible to more cleanly assemble several
lists into a larger list (something that was ugly with the previous
interface).
Enumerators were eliminated because I forsee a need for direct indexing,
and having both mechanisms was just clutter in the interface (IMO).
The list collection object is now broken, and its tests are temporarily
commented out. I also need to write a test for the new move() method.
|
|
|
|
other dynamic lists together.
The ultimate goal is to write a class that places tabs into a notebook,
and that can be used to replace the current top-level view, but will
also work when the view is split by area.
Having containers that emit notifications when they're changed and
that can be accumulated (not coincidentally, the same way tabs are
now) is a step towards having a reasonably clean implementation of
that.
|
|
The expected list is initialized to (1, 2, 3) -- is that right?
Anyway, fix it for now by emptying the expected list.
|
|
|
|
removed item.
This will be useful for implementing a "joint view"; it will allow the
view to be reasonably consistent.
With this addition, the remove() operation is now O(n). Oh well. This
also means that there's not much point in using a multi_index_container
in the impl class; it should be simplified and a vector used instead.
|
|
|
