| 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).
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
documentation.
|
|
|
|
Three changes here. The smaller one is that it now uses dynamic_set
objects instead of dynamic_list objects to store tabs and notifications.
The medium one: explicit signal objects have been replaced with
interface methods for connecting and/or invoking the signal; most
interfaces hide one or the other of these functions.
The large one: tab_info has been redesigned and split into two "role"
interfaces: one showing what the view displaying the tabs should need,
and the other showing what the tab itself needs (to update its icon,
progress, etc). This makes it much clearer what the intended
relationships among the various components of this subsystem are, and
makes it clear in a way that the compiler can enforce. Sadly, this
means I need to use multiple inheritance. (note: it would be less tricky
if I didn't use sigc::trackable -- maybe avoiding that is a good idea?)
|
|
get detached when it's removed.
The multimap is slightly wasteful, but also slightly easier to use here
than a less wasteful container (and it won't make any real difference).
|
|
handlers in the set union.
|
|
|
|
iterator of a dynamic set union.
|
|
reference to a shared_ptr as its first argument.
|
|
and define it in terms of the collection typedef.
|
|
enumerator.
|
|
|
|
I think this is actually the abstraction I want for the toplevel UI;
order should be determined by the view, not hacked into the container
layer.
|
|
concrete view of a dynamic_list_collection.
|
|
|
|
|
