| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
piece of its functionality.
This will make some of the tests easier to write, since often some of
the code requires just the ability to read the screen width, or just the
ability to read input from the terminal. Splitting the terminal interface
means no need to mock out the parts that aren't used.
|
|
As a side effect, this creates a "controllers" directory in the generic tree,
and removes the now-empty GTK+-specific controller and view directories.
The README files are moved over to the generic locations and tweaked to be
correct for their new home.
|
|
|
|
|
|
|
|
Its only real purpose was to do what display_and_advance() does better --
i.e., display a durable progress notification and move to the next line.
|
|
|
|
to the next line.
This should be useful for things like printing a status message alongside
some sort of progress indicator -- set_text() followed by advance() is not
really ideal since it truncates the line.
|
|
implementation for showing the download progress at the command line and a stub implementation.
This is mostly just a streamlining of the apt interface, but putting the
code behind a clean view will also make it much more testable.
|
|
isn't being built.
|
|
If the GTK+ frontend isn't built, neither is the controller,
so the test won't build.
|
|
include file, but I prefer listing all the dependencies anyway.
|
|
separate file to reduce test dependencies.
No reason for tests to pull in half of src/generic/apt just because a module
linked into the test happens to reference a global pointer.
|
|
It looks like I disabled two of them to speed up testing, then accidentally
committed that change.
|
|
current task is done, and for displaying progress the way classic apt tools do.
The new code supports both "[ 40%] Task" and "Task... 40%" display styles,
and when a task is complete the code will either erase it (default) or advance
to the next terminal line (like apt-get does). These behaviors are controlled
by apt options.
|
|
Instead of relying on knowing how many times each routine checks for throttling,
I just fully disable and fully enable throttling depending on whether the next
call should be throttled or not.
|
|
InSequence().
Note that calls to get_screen_width() are left off, since we don't care when
it happens and it can happen any number of times.
|
|
advancing to the next line.
i.e., for explicitly outputting a newline. The main advantage of this is
that it lets me give the progress display a mode that emulates the old apt
progress display (specifically, the behavior that completed steps remain
visible).
|
|
actually changed.
In particular, this means that outputting "\n" after a flush won't
redundantly update the last line.
|
|
isn't a terminal.
|
|
|
|
|
|
One of the tests fails, and it appears to be a legitimate failure.
|
|
terminal mock.
Right now it fails because the terminal's move_to_beginning_of_line() behavior
is completely hidden by an override in the teletype.
|
|
simple transient message would make.
|
|
by the transient message has the effect that it should.
|
|
teletype mock.
I was mixing calls to output() with calls to move_to_beginning_of_line(),
which isn't guaranteed to work. Changed to instead encode the \r outputs
directly into the strings passed to the mock's output() routine.
|
|
move_to_beginning_of_line().
|
|
With terminal output, we usually know how much space should exist
on the left, just not the right.
|
|
This is necessary so that I can test the behavior of terminal output
routines that care about string widths, without depending on system locale
settings or data.
|
|
This will make it easier to deal with wide characters properly in the rest
of the code. I've also found in the other interfaces that it's just a good
idea to use wide strings, to avoid accidentally forgetting a conversion on
I/O.
|
|
to wide characters.
Note that in order to do this, I *had to modify LC_CTYPE for the duration
of the test*. There doesn't seem to be a way around this (short of mocking
out the locale system, which would be nuts), and we might have to do the
same thing in tests of other parts of the system.
Currently these tests fail, because the teletype mock doesn't handle fullwidth
characters.
|
|
Since output to the terminal often paints spaces to erase characters, this should
be useful when testing the terminal-handling code, although it obviously doesn't
cover every case.
|
|
the effect of a sequence of outputs on a normal terminal.
|
|
The new teletype mock will require a terminal; by using a standalone mock,
we can ensure that the tests don't depend on the behavior of the terminal,
which should be tested by its own test.
|
|
to be placed into the output stream.
This is useful because we're normally interested in the relative ordering
of \r with respect to the rest of the text; including it as part of the
same data stream makes it easy to verify that.
|
|
terminal output.
The extra logic is to avoid having tests that depend on exactly how the code
being tested breaks up its terminal writes.
|
|
|
|
Hopefully this will eliminate some of the random crashes
on exit that people were seeing.
|
|
log4cxx provided this ability, so I need it for backwards compatibility.
|
|
All the logging tests pass now.
|
|
|
|
the logging tests to it.
gtest has some nice features for producing extra information in failures
that could be handy. Also, it integrates well with gmock; the gmock
failures in my Boost tests were sometimes kind of obscure.
|
|
|
|
|
|
|
|
|
|
|
|
This modifies the expected behavior to match what I really expect.
Specifically:
* The controller is allowed to set the error message to "".
* After the search text is set to "?installed", the view will return
"?installed' from get_search_text().
Regarding that second point: maybe I should make this "save values and
return them" the default behavior? Although that starts to open up cans
of worms...
|
|
of killing the test forcefully.
|
