| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The behaviour of the non-ept interface has been updated
and corrected, so that, for example, the debtags browser
works correctly.
|
|
When a package is not available or fails to download
incorrectly aptitude would try to continue without it.
This made it hard to detect errors automatically using
the exit status.
This behaviour is no longer the default, instead if there
are missing packages an error will be displayed and the
program exit with failure (100). If the user wishes to
continue anyway, they can use --fix-missing or configure
Aptitude::CmdLine::Fix-Missing in apt.conf.
* [cmdline]: An install run will no longer proceed if any
package was unavailable or failed to download
correctly, instead an error will be shown
and exit with non-zero status (100).
(Closes: #121313, #302784)
The old behaviour can be obtained with the new
--fix-missing option or setting
Aptitude::CmdLine::Fix-Missing.
Closes: #121313
Closes: #302784
|
|
typedef vector<pair<PkgIterator,ref_ptr<structural_match> > > pkg_results_list;
typedef vector<pair<VerIterator,ref_ptr<structural_match> > > ver_results_list;
|
|
|
|
|
|
The resulting functors:
- pkg_name_lt
- pkg_ptr_lt
- ver_name_lt
- ver_ptr_lt
- dep_type_lt
|
|
menu in aptitude-gtk, and remove all references to this menu entry (Closes: #552522)
|
|
|
|
|
|
I'm not sure that it's cleaned up correctly right now; need to double back and check this later on.
|
|
These never worked out as well as I intended, and all indications
were that they would be a maintenance burden...or just bitrot.
Fully parallel builds are nice, but my builds are pretty quick on
my 8-core box even with the artificial chokepoints that automake
induces.
|
|
|
|
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.
|
|
it contains.
Without this I can't build the unit tests.
|
|
|
|
libept.
|
|
objects instead.
This doesn't totally convert the command-line code to using terminal
objects for everything: I/O is still done by accessing stdout directly.
But it does eliminate all dependencies on screen_width.
|
|
Hopefully this will eliminate some of the random crashes
on exit that people were seeing.
|
|
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.
|
|
|
|
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.
|
|
|
|
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?)
|
|
The performance guarantees no longer let this be scalable, and it's
only going to be used for short lists anyway, so scalability isn't that
important.
|
|
|
|
Several changes rolled into this:
* Provide an interface for an append-only list that can emit signals
when stuff is appended or removed. (TODO: index-based operations?)
* Pull out code with no GTK+ dependencies for possible reuse.
Includes the dynamic_list and dynamic_list_impl (above), as well
as progress_info and enumerators.
|
|
|
|
|
|
This seems to be the least worst option I can see. Since my Dist()
builder is outside scons and scons doesn't seem to offer any hooks or
listeners, I can't (safely) cause build files to always be added to the
distribution list. And anyway, I'm not sure I want to.
Better to make the distribution fully explicit.
|
|
Before this can work, I need to add all the SConscript files to the archive
explicitly, which is yucky.
|
