| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
status message.
|
|
|
|
This gives us the freedom to modify its behavior. For instance, this first
cut eliminates the annoying clutter in aptitude's output by deleting the
progress indicator when it's finished, instead of leaving it up. When output
is not a tty (e.g., it's a pipe or a file), the old behavior should be
followed (progress lines are written one after another).
|
|
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.
|
|
Since some test code registers itself with the global logging system,
I want to be able to create local instances of the logging system in
order to verify that it behaves as expected.
|
|
|
|
|
|
Currently unused. Needs test code.
The reason for replacing log4cxx is that on the one hand, it
provides much more functionality than aptitude needs in any
conceivable universe, and on the other hand, it seems to be
buggy and fragile. Just initializing it takes a fairly careful
dance, and it seems to be behind at least some of the sporadic
crashes users are seeing in aptitude. This new code does
exactly what aptitude needs, in a simple and hopefully much
more robust way (possibly a bit slower -- but the fast path
should still be fast; any slowdown *should* be limited to
the situation where we're logging a ton of data).
|
|
|
|
I use google-mock to create a mock implementation of the view, then
test that the logic interacts with it as expected. Right now, it
doesn't.
The ability to do this was part of why I wanted to separate the logic
from the view.
I haven't added google-mock to configure.ac yet; need to do that later.
|
|
Apparently the flag parsing in scons doesn't recognize that "-pg" has to
be passed to *both* the compiler and the linker to be effective.
|
|
library.
|
|
environment instead of the tests build environment.
This is a definite "oops"; it should have been there
all along, but I saw "Boost" and zeroed in on the wrong
part of the program.
|
|
I didn't just use the Autoconf find-a-library macro
because that one changes $LIBS instead of storing the
library in a variable.
|
|
|
|
modularity.
I'm particularly intrigued by the idea of using this to support partial
testing of the GUI components. Even if that doesn't work, I think that
explicitly separating the code that twiddles the GUI from the underlying
program logic makes things a bit readable, although I am a bit worried
about the proliferation of tiny little classes that this could lead to.
The new scheme includes three new directories:
gtk/views/ -- holds interfaces that provide abstracted access to
parts of the GUI.
gtk/view-impls/ -- holds implementations of interfaces from
gtk/views/.
gtk/controllers/ -- holds logic to drive views for various purposes.
The first view/impl/controller set is a refactoring of the search-entry
code. Another thing that concerns me: it's not clear that there are
actually very many places in the existing code-base that can be
cleanly refactored to fit this mold.
The new search controller/view classes drop support for incremental
searches. This is deliberate; I see two major problems with the
existing code.
First, it requires an extra button in the UI to enable or disable it.
That bothers me; if incremental search is worthwhile, it should be
enabled all the time, at least by default (IMO). Second, the existing
code was really ugly, partly because of the way the code used to be
designed (before searches ran in the background). It should be
reimplemented from scratch anyway.
|
|
|
|
of the current tab.
I envision some tabs being created in multiple areas; their
sub-tabs should be siblings. Having this code centralized avoids
any need to store backlinks manually from other parts of the
program. (I hope)
|
|
This was always the intention -- I just wrote the wrong type into
the function signatures.
|
|
available along with the main window.
This commit also adds a wrapper interface for the main window; the idea
is to use it to provide information that's "scoped" to a single main
window, but that may or may not be physically stored in it.
The first piece of window-scoped information is the model that backs
the window, providing a list of the areas in the window and the tabs
in each area.
|
|
implementation.
Now we can actually invoke it without getting errors back.
|
|
.gitignore.
|
|
It doesn't #include enough stuff, so trying to compile it fails.
|
|
|
|
other than the ones for the Boost check.
The test I wrote is crude; it would be better to put explicit marker
lines in and use awk or somesuch. OTOH, I hope configure.ac will die a
horrible death soon, so maybe not worth putting a lot of effort into
this.
|
|
|
|
interfere with Makefile builds in the same source tree.
|
|
|
|
|
|
|
|
|
|
uses when invoking the function it's passed.
With this change, aptitude should no longer require boost >= 1.42 to
build.
|
|
This will be the foundation for the new top-level harness code.
Eventually the old code will go away, but I don't want to disrupt it
while I'm working on the new stuff.
To activate the new code, pass --new-gui on the command-line.
|
|
|
|
I used boost::function<> because it's flexible and doesn't require
awkward syntax or metaprogramming. It's slightly less efficient than
it could be, but this isn't supposed to be time-critical code anyway.
|
|
|
|
implementation.
The idea is to eventually transfer all the AptiutdeWindow code over
here, or possibly refactor it to be better organized.
|
|
|
|
|
|
|
|
time.
This will be needed by the main window, so it can update menu items
appropriately and so on.
|
|
|
|
|
|
The idea here is to (eventually) replicate the behavior of the current
TabManager, and to support a "classic" set of flat tabs, along with some
more experimental UI designs. Currently missing some (relatively) easy
features like changing tab titles, tab tooltips, etc.
|
|
infrastructural code should connect to this.
|
|
Now you can tell by inspection whether a tab has been destroyed, and the
destruction is triggered when it's removed from a set rather than when
the closed signal is emitted.
|
|
tab probably want to catch.
Without this, they would probably end up building weak_ptrs and binding
those into the signal connection; this is a bit cleaner.
|
|
|
